The Importance of Identity Standards with Pamela Dingle

Vittorio Bertocci: Buongiorno everybody and welcome. This is Identity Unlocked and I'm your host, Vittorio Bertocci. Identity Unlocked is the podcast that discusses identity specs and trends from a developer perspective. Identity, Unlocked is powered by Auth0. Our esteemed guest today is Pamela Dingle, Director of Identity Standards at Microsoft, and the founding member of Women in ID. Welcome, Pam.

Pamela Dingle: Hello, it's so great to be here.

Vittorio Bertocci: Thanks for joining me today. Can we start with how you ended up working in Identity? I'm sure it's going to be a fascinating-

Pamela Dingle: Well, probably not, but I'm telling it anyway, so you'll have to listen to it. So I am originally from Canada and I got into the identity world because I was flying to California to do middleware work. So I was a system administrator, back in the day and I was being flown as the cheap Canadian labor into Silicon Valley in order to install middleware. The middleware that I was installing ended up being directory servers, in addition to mail servers and web servers. And I started to get really interested in not just the systems, but in what we were actually storing. And really where I got hooked was at a web conference. Well, actually an in-person conference. I ended up at a conference called the Burton Group Catalyst Conference, which by the way, is where I met you, Vittorio.

Vittorio Bertocci: All right.

Pamela Dingle: And I got there and there were a thousand people all talking about the same things that I thought were cool. And so I ended up standing up and asking questions and getting very excited and very involved. And what happened was the organizer of the conference, his name is Jamie Lewis, some of you might recognize that name, came to me at the end of the conference and said," You did a really great job. You really distinguished yourself. You should present an abstract, you should put an abstract in for next year's conference." And so I got really excited, I was very encouraged by this, so I created an abstract and it was rejected. And then the next year I created an abstract and it was rejected. So for any of you out there who are having trouble breaking into the conference speaking circuit, please know that everyone goes through that problem. But during that entire time, I was meeting people and talking and gaining relationships that were international and being part of these conversations about identity on the Internet and it changed my whole approach to life and to my career. And so I ended up getting involved with a thing called InfoCard and doing a lot of work, writing open source information cards, plugins for WordPress and Joomla, things like that. And that's how I got into identity, it sort of took off after that.

Vittorio Bertocci: Very nice, and what was your professional trajectory that led you to your current position?

Pamela Dingle: So after I started working on InfoCard, I was invited to interview at a company called Ping Identity. For those of you who don't know Ping Identity, it makes federation products among other things, and I got to go work in the office of the CTO at Ping Identity. I worked there for eight years, had a wonderful time and then got the opportunity to come to Microsoft. So that was my first time working for a vendor, creating software, and it was great experience.

Vittorio Bertocci: Very nice, fantastic. Well, in Microsoft your focus is precisely the topic of today's episode, which is Identity Standard.

Pamela Dingle: That is correct.

Vittorio Bertocci: That's correct. Very nice, perfect. So finally we will unveil the mystery of how standards work. So can you tell us a bit about what standards are?

Pamela Dingle: Yes, I absolutely can. And I will start with an analogy and that is, imagine a world where you had to directly wire every single lamp, every single appliance in your home, into your power grid. Imagine that world where nothing is done for you, where you have to go figure it out. You have to calculate the voltage, capacities, the current, everything. Well, that world is hard, it's difficult. What standards do, is they allow you to make assumptions about the predictability of the system that you're working in. So when I pick up a lamp and I hold the plug, that's going to slide into the wall, I don't have to understand what that means. I don't have to understand how many volts the appliance is rated for. I don't have to understand if it's direct current or alternating current because somebody else has devised a set of interfaces that abstract that away. Right. So from a developer point of view, we're really talking about layers of abstraction that you can put over top of things that occur either on the wire, right? Usually using HTTPS, but also there are specifications for everything you do in daily life. For example, why do your dishes fit in the dishwasher. Well, that's probably more of a convention. So there's in a lot of ways, standards are conventions where everyone does things in a common way and they find value in it, that then turn into strict codifications so that we can all conform. So there's a relationship between interoperability, predictability, reliability, and common preferences and usage.

Vittorio Bertocci: That's a fantastic analogy, I absolutely love it. But anyway, the advantage is clear. The thing that is as clear is given that the world moves toward growing entropy, instead what you described is a situation of beautiful order and symmetry- clearly it's not something that just happens spontaneously, but there must've been some kind of effort here. So how did we go from a Cambrian explosion of people jerry-rigging lamps together to today's beautifully regulated world as standard?

Pamela Dingle: That's a great question. I don't know how it evolved. I mean, I don't know what the Genesis of some of these standards organizations are, but I can tell you-

Vittorio Bertocci: I think what Tony Nadalin decided one day that we had to be regulated and he was still wearing his suit and things happened. I think we can thank him for a lot of stuff.

Pamela Dingle: I would say that behind every warning sign is an initial incident. So I'm guessing that a bunch of things really went wrong that made people decide that they needed to get together and create more specific rules on how systems should evolve. In the identity world, the standards that really are the basis in the identity world are Kerberos. And a precursor to LDAP, which I think was, I would say X.500, I think.

Vittorio Bertocci: Yeah. It's far enough in the past that we can probably happily...

Pamela Dingle: Far enough in the past, but you know who you should put on this podcast is Dale Olds.

Vittorio Bertocci: and Mark Wahl.

Vittorio Bertocci: Yes. Mark as well. If you had the Mark and Dale, each separately, Dale Olds was one of the primary inventors of NDS in Novell world. And so he has a very different view on how LDAP and how Lightweight Directory Access Protocol evolved. That's what we're talking about, for those of you who aren't familiar with LDAP, it was one of the very first standards that allowed you to apply a layer of abstraction to identity in-depth what you could do is centralize your credentials in a single place. So you could, instead of every single application, everywhere storing passwords, you could store them in one place. And then you could ask for them from anywhere. Now at the time, anywhere was it within a network perimeter.

Vittorio Bertocci: Of course. Yeah. Those were the days. And I think that one of the first standards that actually was by design created for spanning multiple perimeters was a SAML. SAML started with the Liberty Alliance-

Pamela Dingle: I do.

Vittorio Bertocci: Remember, do we want to start from there? Or do we want to start with something more modern?

Pamela Dingle: A think SAML really good place to start in fact, and to give you an idea of how old SAML is and possibly how old I am. When I came to my very first identity conference, the one I talked about earlier, that was the conference where Liberty Alliance was really kicking off and where in that case, this desire for cross-domain secure, what I call secure introductions across domains was very strong. And part of that was because there was a concern at the time over any one company really owning that space. So part of the reason why SAML came to be was the idea that any identity provider could own and operate their own engine to make assertions about people, and by assertions, when I talk about SAML, I talk about it as a secure introduction. So, there's a lot of terms that fly around here. At the time, there was no real concept of REST. There was no concept of what we would call a back-channel interaction. I mean, there were back-channel interactions, but from a web perspective, the most common SAML interaction that we have now is what's called SAML POST profile. Right. And that is really about only using HTTP POSTs to send in a request, to get a response back.

Vittorio Bertocci: Right. And adjusted to translate this, in very concrete terms, we could say that SAML was designed for helping facilitate web Single Sign-On. So you have a browser, you open it, you go up to a certain website, you authenticated part of that. And then you go to another website and magic, you are authenticated in there without having to enter credentials. And that was all there was. It was like the main problem being solved. And so everything was in what we called, the so-called front channels.

Pamela Dingle: It was front channels. So the irony of that is that the SAML POST profile is really the only thing that has survived. But if you were in that standards body, if you were in the Liberty Alliance at that time debating, and I was not there, but what I do know is that they covered all sorts of use cases. They covered far more than web Single Sign-On there's another one called, I believe, ECP proxy, which was in fact, meant to deal with some of the use cases, similar to OpenID Connect and OAuth, meaning you have a client proxy. It was the idea that you had active software that might want to make requests without browsers. So that data was there, that desire, and those use cases were there, but at the time the underlying technology was different and the assumptions that you could make were different. And so that working group actually came up with a whole bunch of really brilliant work, that in some sense was ahead of its time. And enough ahead of its time, that by the time we got to the point again, where active software was a common phenomenon, we also had a number of other changed properties like cloud platforms, REST API, and most importantly mobile platforms.

Vittorio Bertocci: That was fun. But before we get into the next steps of evolution, let's pause for a moment on Liberty Alliance in itself, because that was a good example of organization standard and a very different institution than today's standards. So can you tell me a bit more about who was in a Liberty Alliance? How did it operate?

Pamela Dingle: Yeah. The Liberty Alliance, and just know that I wasn't there for that, so this is my outside opinion rather than any kind of inside opinion. But the thing about Liberty Alliance was that the big players were there and this is really the thing about standards bodies even today, is that you have to have the right community present. You can write any standard you want, but if you don't have the right people at the table, then they don't get adopted and they don't get used. So when making standards, there are these critical ingredients that have to exist, including having the right people at the table and having them work at the right level to create the right amount of data, and the right types of documents. But in the Liberty Alliance case, the big players then, RSA was there, Sun was there. There were, a lot of these big players were in the room. And what they created was very, at the end of the day, quite formal, formal enough for that the outcome of the standards document creation also resulted in a conformance test. And that back in the day, for example, when I started at Ping was just sort of at the point where those conformance tests began being less important. But in those days, if you wanted to write a product and you want it to be SAML compliant, you had to go get a quite expensive certification to say that you could comply with this profile or that profile, the education profile, so on and so forth. The folks that were writing the documents. But then there was this very strict sense of, whether you get to say, you can perform those SAML validations or issue assertions also.

Vittorio Bertocci: And expensive is really a keyword here, because back in the day, in order to even participate in the discussion, you had to be accredited with one of the companies that were part of the organization. There was a fee, the meetings were in expensive hotels here and there. So it was a very enterprisey affair. And today we are no longer operating in those terms. Right?

Pamela Dingle: Yes. So I will say that the travel, so expensive locations is a bit of a hallmark of at least the identity standards bodies. And part of that is an effort in adding inclusion. So for many of the standards bodies that my group works in, for example, this would include the IETF, ISO, OpenID Foundation less so. The standards bodies often choose three physical locations in order to have their meetings. And the reason that they do that is that gives opportunities to each of the time zones in the world, to make sure that there's not a bias towards all American participation or European participation or Asia Pacific participation. So this has been a fairly common pattern right up until COVID-19 hit. Was to get people in the room to actually talk in person.

Vittorio Bertocci: Right. And in this particular case, the interesting part is -there are these important milestones for the year in which there are high bandwidth in-person conversations, which of course now all occur virtually. But the point is that if someone wants to participate in a discussion, that you no longer need to belong to some big company. Like you mentioned the IETF, can you expand a bit, for example, on what the IETF is, what it does, and how people participate?

Pamela Dingle: Yes. Every standards organization has its own flavor, has its own culture and rules and they do, they have different amounts of enterprise requirement to them. So IETF everyone joins as an individual. There's lots of opportunities, as I understand it, that for individuals to sort of participate and to be part of the mailing lists and to be a part of the working groups in an IETF situation, IETF has this concept of area directors. In some sense, a hierarchical world where they do have people who are trying to curate different areas of technology. There are other standards bodies that have different cultures. For example, W3C is another standards body. A W3C is generally where the browser community is. So if you're trying to work on browser-related topics, you generally want to work in the W3C. And examples of what's happening in W3C in the identity world would include the credential, the CredMan API, and the web WebAuthn API. Those two are both related to each other. And a lot of the browser identity-related things, Privacy Pass is another one that's going on right now, for example. So those tend to have different people in them. And those different people are trying to accomplish different things. In IETF, the folks who are there are generally more on the wire people. So you get lots of networking folks, you get lots of people doing the direct transfer stuff. So OAuth is an example of a working group that runs in IETF.

Vittorio Bertocci: And ultimately, although of course, there are cultural differences and differences in focus on the particular topic, but in general, the playbook is similar, as in there are documents, which might be called RFCs, which might be called something else, depending on the flavor. And those documents enshrine descriptions of a particular scenario of a particular aspect that the standard wants to regulate, and describe and provide the norms for. And then all these discussions are about minutiae on the particular details.

Pamela Dingle: Yes, this is correct. So the idea of all of these working groups is to create something that is static. It is a snapshot in time. It describes a set of rules that everybody can adhere to. And the assumption is that if you adhere to the rules, then you and anyone else who also adheres to the rules will be able to communicate and achieve whatever the standard is designed to do. So there are many examples of how this might work. In identity, Single Sign-On is a big one, Federation, which as I said, I call it a secure introduction, meaning that if you follow the rules for either OpenID Connect or for SAML, then what should happen is you will play a role. And in that role, you have a job to do in order to be secure. And so an example of this would be the relying party role, and the whole idea of a relying party role is that you are going to be... Someone who's going to introduce a user to you. And you have a job as a relying party in order to be sure that that introduction is secure, that it's coming from the right party, that it hasn't been counterfeited or intercepted. And so in theory, if that's the role you want to play, you want to play the role of relying party. Then you're going to go find the specification. That explains how to do that. In this case, it would probably be OpenID Connect Core, and you would read that. And then you would follow those codified instructions and you should be able to know on what date that document was written, you should be able to know what version that document is, and you should be able to negotiate with the other party to be sure that they're going to use the same version and think this is the equivalent set of instructions so that you can have an assurance of success.

Vittorio Bertocci: And given that you mentioned that OpenID Connect does not come from the IETF, nor the W3C, right? From where does it come from?

Pamela Dingle: That is correct. So OpenID Connect comes from the OpenID Foundation. And the OpenID foundation is a foundation that is open for anyone to join. So I believe it costs around$ 25 for an individual to join. And they have working groups for OpenID Connect. For those of you who do not know the relationship between OpenID Connect and OAuth. OpenID Connect is a profile that adds identity information to an OAuth interaction. So in this case, this is a case of a working group that is relying on the output of another standards body. You have to understand OAuth from the IETF and you have to understand OpenID Connect from the OpenID Foundation in order to be able to do web single Sign-On.

Vittorio Bertocci: So all of these standards bodies, all these participants, you mentioned that it's important to have the right people that participate. There is a lot of overlap between those teams, right? I know that, like yourself, you are in a leadership position. So of course you needed to have your paw in many jars, but a lot of individual contributors, contribute to both OAuth, OpenID Connect, and similar, right?

Pamela Dingle: Yes, some people are professional standards people, and some folks really only care about a specific area. So you'll find that there's a mix of people in these specification groups. Some of them are deep subject matter experts, only in tokens or only in telephony or only in networking. And some folks actually move across the top. There are some folks, for example, who are professional standards body chairs. So, they don't so much specialize in the tech itself, but where they do specialize in is getting a good output from the subject matter experts that are in the group. So what they're good at is process, because one of the critical parts of a standards body is A, ensuring that everyone's heard, but B, driving consensus. And so the techniques for driving consensus are podcasts all in their own, but at some point you can't let people talk about possibilities forever. At some point, you actually have to decide what bits go on paper and what details matter. And various groups will push back in various ways, depending on what's important to them. So that whole idea of allowing everyone to get the pieces that are important into the specification, while still ending up with a product that achieves this actual goal, that's the magic.

Vittorio Bertocci: It's really hard. Getting consensus is so difficult because everyone has their scenario very clear. And so that's what they want enshrined in the document. But everyone has different experiences, like in these standards. I remember when DPOP came out and it's a fantastic idea, but then some of the ultra-large vendors, like the ones with a really, really a lot of scale challenges, just their sheer size came back and said," Hey, you are using asymmetric crypto. And at the scale at which we operate, it's just not workable." So these kinds of interactions that people that don't have it to operate at that scale, don't even think about. Like illuminating moments saying," Oh, wow. Yeah, we do need to have this forum in which different people come together and bring those different perspectives.

Pamela Dingle: Yes, absolutely. And when you create a spec and it doesn't have that, then what happens is you create confusion later, you create difficulty later. So being able to know upfront what's important, what isn't, is a huge deal. There are times though, where nobody knows, nobody realizes the impact of a decision that gets made. And so those are always interesting times. I would give an example. I think of PKCE, would be an example of that. Had the working group in OAuth and the IETF, had a magic crystal ball. They would have known that theft of the authorization code in a OAuth flow would be a problem. And they would have solved the problem right up front, they didn't. So what happened was, you can actually go lift this up. PKCE is the OAuth specification. And they had to write a separate profile that goes on later to the specification that solves this very important security issue of theft of the authorization code. And it would be better if it was all one, because the one thing I will say is that because consensus is difficult. And because we are trying to find something that everyone does anything that's optional becomes problematic. So this is the art of standards is making sure that people have not many choices, but few. Just enough choice for them to suit their business needs, but not so much choice that everyone has to implement a whole bunch of different conditions as part of them having to support the standard.

Vittorio Bertocci: It really is very hard. Because I'm finding where the boundary between prescriptive and freedom, like OAuth is extraordinarily successful, but it's also not particularly well interoperating, it teaches you to be a client, but leaves so many details out that when you know that the A and B both support OAuth, you don't necessarily know whether they can talk to each other. Whereas you can make that statement when A and B are doing SAML or OpenID Connect.

Pamela Dingle: It's true. Although I would say that the difference between SAML and OpenID Connect is that they were designed to cross domains. For me, from my perspective. OAuth authorization server was primarily formed to be able to communicate with things that you control. So the whole reason why an access token is opaque to a client is because that client is that side of your world. We've given easy instructions for how clients can use access tokens, specifically because we don't want them to all have to understand every in and out of what's inside an access token, at least that's how it started.

Vittorio Bertocci: Right. You are talking to the wrong guy in there because the spec that I'm driving is exactly one that is formalizing something that the market has done on its own anyway, which is to actually use a recognizable format. But yes, I get the point as in OAuth was focused on just the client, stuff that gets the token, and uses the token, rather than consume the token, and then there was this underlying assumption that the resource server and the authorization server. So the one that consume the token and the one that emits the token were largely co-located. Like classic Facebook gives you a token and Facebook also exposes the graph. And so when you send that token, it could be just the link to a row in a table, and the table is written by both the consumer and the producer, whereas in the real world, especially businesses like Microsoft and Auth0, you do have an authorization server in one place and the consumer of the token in a completely different place. And so you can't rely on them reading the same table. So you've got to find some tricks and sure, there is introspection, but that's very expensive. And so that's why almost everyone on the planet uses JWT as a format. And again, this is a testament to adding the correct extensibility points in the standard. Like OAuth is great, because it has the right extensibility for adding a posteriori a lot of the things that you mentioned there.

Pamela Dingle: I think too, if you compare the SAML world and how it evolved at the beginning to the OpenID Connect world and how it evolved, going back to that topic of standards bodies and how standards bodies work. One thing we do very well in identity is we react to what has come before. So I was in fact there for the OpenID Connect discussions compared to the SAML discussions. And one of the things that the editors were very determined to do when OAuth was created was to ensure that they did not create a monster specification, because the SAML specification was something like 800 pages. And imagine you're a developer, who's trying to go and learn how that works. Well, 800 pages is a little daunting, And so when you look at the OAuth specification in IETF, it is short, but there are many. So they've gone the route of creating a short spec that did just enough and allowing for profiles to extend it. And there are advantages and disadvantages, but I think the advantages outweigh the disadvantages in this case. You don't have to adopt the pieces you don't want to, and you can still be conformant to a given tiny baby spec.

Vittorio Bertocci: And of course, for us, we say short spec because we are anchored to the 800 pages of SAML, but for the normal person, the normal developer who cares about the productivity and not as much about the identity, the 60, 70 pages that are typical of our new world.. I guess, but most people can actually just use SDKs with the comfort of knowing that, given that they are all using standards, the scenario that you nicely described earlier about being able to plug the lamp into the wall, you don't even need to know the voltage. You just know that the manufactured out of a lamp followed that standard. And so when you buy it, you know, you can plug it in your wall.

Pamela Dingle: Yes. I think many developers won't read those specifications and in that case, using an SDK or a library is valuable because there are edge cases that need to be taken care of. But the number one requirement, as far as I'm concerned for developers is for them to remember that in these kinds of access management use case, the happy path is not that the user gets in. It's not that the assertion arrives and the user has access to their resource. The happy path is when it fails, the happy path is kicking out the wrong people. And we have seen examples of implementations that have gone all the way to production where not only can the right people get in, but everyone else can get in too. So simple things like validating your signature are absolutely critical. And if you set these things up without testing, that's when I get scared.

Vittorio Bertocci: Yeah, absolutely. That's a fantastic point. And again, the value of standards is where a lot of people list the things that should be done in order to prevent exactly what you just said. And if you follow the standard, if the SDK you use follows the standard, you'll be sitting on the cumulative wisdom of all these people in the community. Fantastic. Before we part ways I wanted to ask you about Women in ID, I know you are involved in that. I'd like to hear more about what it is about, and if there is any call to action that you can think of.

Pamela Dingle: Yes, absolutely. Women In Identity is a grassroots organization, but we have quite a large following now. We have something like 4,000 fans and 1,300 members. And we have an amazing group of ambassadors all over the world that organize local communities and local events there. For example, we have, I think something like 400 people in Canada alone.

Vittorio Bertocci: Fantastic.

Pamela Dingle: Yeah. It's really fun. The reason why it grew and why we created it was because for a lot of women in our field, they feel alone. So maybe you're the only woman who's doing identity in your given company. There are a lot of us out there. And so what Women in Identity is we are dedicated to diversity, not only for women, but diversity in general, but we also have this belief that we can help each other, that we can be seen. We can raise our own visibility and we can support each other and we can do good in the identity world as well. And if you're interested in that and it's not just for women. So if you're an ally, you're welcome to join and be part of this, we are as inclusive as we possibly can be. And we're always open-minded as far as how we can be better, but where do you want to go to is womeninidentity.org. If you go there, you can find a link that will let you join and become a member and come be part of our community.

Vittorio Bertocci: Wonderful. That's a great initiative. And I know a lot of people are absolutely enthusiastic about how useful this has been for them to feel part of a community and exchange opinions with other experts. Its a great initiative and we'll make sure to add the link in the podcast description.

Pamela Dingle: Fantastic.

Vittorio Bertocci: Well, Pam, thank you so much for your time. It was really great to have you on the episode. And I believe that this is going to be so useful for so many people that have been using the standards, but didn't really fully grasp what that really meant.

Pamela Dingle: Well, thank you. I really appreciate the opportunity to come on and chat. It's always a good time.

Vittorio Bertocci: Wonderful. Thank you again. And thanks everyone for tuning in, until next time. Thanks everyone for listening. Subscribe to our podcast on your favorite app or at identityunlocked.com. Until next time. I'm Vittorio Bertocci and this is Identity, Unlocked. Music for this podcast composed And performed by Marcelo Wolosky. Identity, Unlocked is powered by Auth0.