SignIn.org and the Genesis of the GNAP Working Group

Vittorio Bertocci: Hello, this is an update from your host, Vittorio. We recorded this episode in August. At the time, the working group did not select a draft yet and the interview content reflects that. Since then, the working group did select a draft eventually. You can find the relevant link in the episode notes, enjoy the show. 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. In this episode, we focus on the grant negotiation and authorization protocol. Our esteemed guest today is Dick Hardt, founder at SignIn.org, of Identity 2.0 fame and among other things, author of OAuth 2 specification. Welcome, Dick.

Dick Hardt: Thank you.

Vittorio Bertocci: Thanks for joining me today. It is traditional that we start with a short summary of your journey that brought you on working on identity. Would you share that with us?

Dick Hardt: Sure. I'm probably a little older than, well I know I'm older than you Vittorio. My undergrad was in mechanical engineering and I started fiddling around with Windows 103 and as I found in my career, I was always very early in each sort of new technology wave. I was working on mail systems back in '87, had a startup and was working with neural networks back in the early 90s.

Vittorio Bertocci: Wow.

Dick Hardt: And then in '93, I was at a consulting company and I hooked them up to the internet so we could mail our customers - little nailed up 28K line. And then I got into the early days of web hosting, but I've been working on Windows and everyone was using Perl. So I talked Microsoft into paying me to port Perl over the Windows, and that led to starting up a company ActiveState with O'Reilly and Associates. Tim was on my board, very fun working with him.

Vittorio Bertocci: Nice.

Dick Hardt: And so we were an open source company a couple of years before open source had been defined and then we sort of pivoted in the company as spam became a big issue. And one of the top pieces of tech for working with spam was SpamAssassin written in Perl. We know how to make Perl run fast with Sendmail. And so we got into the anti- spam business, which also partly is somewhat of the identity business because you want to know who is the sender. That took off and became most of our revenue and led to the sale of the company. But before we did that, we'd also gotten into working with O'Reilly and Associates, who we had a marketing relationship with. And so I got thinking well, it'd be great if somebody signs up for one of our websites that they could just click a button and sign up for the other website. You know we had over a million users a month coming through our site. They had a lot of the same users. And so we were trying to figure out how do we do that? That's kind of really how I got started into identity.

Vittorio Bertocci: Very nice.

Dick Hardt: I founded a company, Skip Identity. We were trying to go and solve internet identity. Once again, I was super early. That migrated into becoming the OpenID protocol. We created the OpenID Foundation because IETF people were mean to us and sent us away. And so he says," Okay, we'll just take all of our toys and create our own sandbox."

Vittorio Bertocci: Nice.

Dick Hardt: And then I went and worked at Microsoft and the OAuth1 had come out and I'd sort of just been tracking what had happened, but it was pretty complicated for people to deploy. They had to go and sign things. And a lot of that was because they had a requirement of not wanting to use TLS. I sat back and I thought, you know I don't know that that's such a hard requirement anymore. And so myself and Adam from Yahoo, and who was it from Google, and one of my colleagues at Microsoft, sort of started working together. We wanted to call it OAuth but Eran Hammer-Lahav that was working on OAuth, didn't want it to be OAuth unless it was building on top of OAuth. So we give it a new name Wrap and we rolled it out at an IIW. Then although OAuth people were kind of freaking out because it was really the same problem as OAuth. So we agreed to call it OAuth Wrap, which of course what we wanted to do was call it something OAuth. Then at the same time, the standardization was starting to happen of OAuth and IETF. So I presented the OAuth, the Wrap stuff at IETF, and that it was the basis for what became OAuth2. And when I was at Microsoft, I also worked on what eventually became JSON Web Tokens because we know we wanted a token format for people that didn't already have a token, but we didn't want to dictate the token an OAuth. And then after that, I just kept doing identity stuff, did a bunch of consulting. And eventually, Amazon convinced me to go and join them. When I was there, I drove what's now the FastFed standard that's coming up because of all the pain, and people, just the control plane of setting up Federation. We had Federation standards for how everything talked together, but it would take somebody that wasn't familiar with it a couple of weeks to get it all up and running. So FastFed's goal is to make it so people can just click through and federate so that more and more of enterprises, even if you only got 10 people, if you're using Azure or Google for your email, which you probably are, that you just clicked through and federate to GitHub or whatever else without having to create new accounts for everybody. And I also got active in RISC, which was an OpenID protocol for sharing events. And then I was also working on security events. And now I'm on SignIn.org to go and solve internet identity once again.

Vittorio Bertocci: Nice. I guess we have to wait to hear more about that in a second. Wow. That was very impressive, you clearly were early on everything. You had your hands in so many things that are ultra relevant today. And it just so we continue that tradition. When did we meet again? I have a feeling that we've been like running into each other since forever. Like the earliest memory I have of you, it was at some IIW when we were still working on information cards. Do you remember when we met?

Dick Hardt: I think that I remember sort of around that time, but I've just got this strong memory of you talking somewhere loudly and me thinking oh, it looks like a real fun guy. I should get to know him.

Vittorio Bertocci: Nice. I'm very glad that we eventually did. And it's been a really nice ride. Wonderful, fantastic. This was a powerful introduction. It's going to be hard to top it. Thanks again for being willing to discuss this new initiative, which just recently got christened GNAP, which stands for Grant Negotiation and Authorization Protocol. It's a new initiative just drafted recently. And I'd love to hear from one of its protagonists, that would be you, what it is about. Like in particular, what is it and what is a high level, the problem that it's trying to solve?

Dick Hardt: Well, I think to talk about GNAP, you need to sort of go back to OAuth and OpenID Connect and what's happening in those two areas. OAuth is now 10 years old and the world has changed dramatically. Mobile phones are the most popular way for people to log into things. The web is still important, but a lot of browser mechanisms have changed as browsers are trying to be more privacy-protecting. OAuth has been wildly successful as a protocol. And so people are trying to squish it into doing things that weren't really what it was initially designed for. And there was also, because of any standard, some politics going on, there were some features in OAuth that I wasn't super keen about. But okay, as long as we don't abuse that, that's okay. But of course, people use those things incorrectly and we've had to go and tune-up what best practices are and things. And so of course there's the OAuth2.1 work, which I'm involved in, which is really just taking all of the OAuth2 stuff, all the best practices, and putting it all in one document so people can easily understand what's going on. But there's a lot of other really interesting things going on around what people are trying to do. They're trying to do much more advanced identity protocols. And OAuth wasn't designed for identity, for authentication. It was designed for authorization and OpenID Connect layered on top of that. There's been always these issues of sort of the front channel of it being very web browser oriented. And OAuth and a bunch of thinking on it a little, maybe we can start off backchannel. And then another thing is, well, rather than having a client ID in secret, which is a shared secret, which as you start to go and build much more distributed applications is problematic around how do you move that secret? Getting that secret to things has been one of the big challenges because a number of things can't have a secret. And so then how do they identify themselves? But today, unlike 10 years ago, asymmetric cryptography, public key cryptography, the machinery is much faster. The APIs are much more widely available. It's a much easier technology to work with. You now have asymmetric crypto APIs available in browsers. Just for people that aren't familiar with what that is, it's really where you have one key to sign things or to encrypt things and a different key to verify things or decrypt them. In general, what we're using this for is really signing and verifying it. But no, now you're not trying to share a secret between the two parties that are communicating. The party that's getting it just has a public key. So it can't pretend to be the other party, which gives you a lot better security principles. And so with that, you can start to have the client in an OAuth model. You know, the thing that wants access resources can just say, "I got a key pair, here's my public key." And you can do what's called Trust On First Use, where the first time that client goes through the flow with a user present, the user says, "Yes, I trust that client." And then that same client can go and say it's the same client again all the time. But nothing else can prove that they're that client because it's the only one that has that private key.

Vittorio Bertocci: So let me pause you there because we are digging super deep, super fast. And let me try to summarize. Basically, what you did there was identifying a number of areas where the calendar design of OAuth doesn't really take into account some of the new scenarios that emerged in the meanwhile since the moment which OAuth was created. And some of the mechanics that OAuth relies upon, which were again, a product of a time in which OAuth was designed, are now not taking advantage of some of the things that instead we could do which work better, but that weren't inshrined in the OAuth core back in the day.

Dick Hardt: Yes.

Vittorio Bertocci: How am I going?

Dick Hardt: Yes.

Vittorio Bertocci: Is these. Okay, perfect. Great.

Dick Hardt: I'm just looking at my notes and I have a nice little cheat sheet of what are the main issues in OAuth2. So one of those is the front channel security bouncing back and forth through the front channel. Now we've addressed that with something that we refer to as PKCE, P-K-C-E, which is sort of a bit of signing so that it helps that, but you know, it's extra work to do that. Now another issue is the... what you can ask for in the request when a client wants access to some resources, constrained because you're trying to push all of that over the front channel in our browser redirect. There's a new standard being evolved called PAR for pushing and authorization requests, and RAR for rich access within OAuth. But you're tacking these onto OAuth, near term, those are great solutions. But stepping back, the idea of GNAP is now that we have a new world and a new, better understanding of a much broader set of use cases. Is there a better way, easier way, simpler way to do the same things, and also to make it easy to do things we couldn't easily do before? You know, another issue with OAuth2 is sort of all the different endpoints I already talked about how do you authenticate dynamic clients and issues of shared secrets? And it wasn't designed for authentication.

Vittorio Bertocci: Great. So let me, again, summarize the part that you mentioned so far. The essence is OAuth has extensibility points baked in and IETF is taken advantage of those extensibility points so that some of those extra capabilities are being layered on top of OAuth. What you are suggesting is that although that works longer term, it's possibly more efficient to backtrack instead of dealing with the constraints of general OAuth design. If you start from scratch, and if you bake in some of these newer requirements, then you'll end up with an easier specification.

Dick Hardt: Yep.

Vittorio Bertocci: Is that along the lines of what you were saying?

Dick Hardt: Yes. I mean, I would say that a number of the extension points, how people are extending OAuth weren't necessarily designed extension points, but they're logical extension points because of the technologies that OAuth was built on. But it does touch on another one of the design goals of GNAP, which is we have a better idea of where extensions might happen. So let's design in extension points so that it's really straight forward how to add and extend GNAP in a number of different dimensions.

Vittorio Bertocci: Perfect it makes a lot of sense. And here, just because we try in here to maintain both perspectives, as in the perspective of the protocol design and the perspective of the people building solutions on top of those protocols. One thing that I just wanted to make sure that we clarify is that from the point of view of someone that is consuming, let's say, a library of some kind, and these library implements either OAuth plus extensions, or the new protocol. From the point of view of expressive power, those things that you are trying and to achieve in GNAP are still achievable with what you have today with OAuth extensions. Is just that if you open these SDK and you see what's inside, in the case of GNAP you'll see something more clean, modern, well- designed, better engineered. Whereas in OAuth you might see a number of the jury-rigged extensions. But ultimately from the point of view of a developer, those things that you mentioned are possible already today, with OAuth plus extensions, correct?

Dick Hardt: Well, there's some new things that we're experimenting with in GNAP that are not part of any of the extensions in OAuth. And in many ways, that is what motivated me to get involved in GNAP was there is features that I wanted to have in SignIn.org, where there's no straightforward way to include that in OAuth2. For what developers are doing today, they should just keep using it. And I think, as you say, a lot of libraries are going to support both, and it may not really matter to the developer for what they're doing. But longterm, there's probably some functionality that will only be provided through a GNAP interface. But all of that functionality is... Those are just experiments now. There isn't anything deployed that is using anything like that, and none of those things are really figured out. But it's a lot easier to experiment with those things in GNAP than trying to layer them onto OAuth. And we can dig into one of those if you'd like.

Vittorio Bertocci: I would absolutely love to. But at this point, I think it might be interesting to take a little step back, consider, given that it's just happened, how it coalesced, how GNAP coalesced into a working group, what was the genesis. I think it's interesting to see how this new island emerged from the ocean, given that you are at the very center, I'm really curious to hear how you tell the tale over how GNAP came to be.

Dick Hardt: Sure. So, first of all, I wouldn't say that I was at the center of it until recently. And I can share what I know about how everything happened. So a lot of the concepts in GNAP were part of something called transactional authorization, or TX Auth, that Justin Richer was working on, has been working on. He's been trying to promote and get people excited about it for a number of years. He cornered me one time at one of the things and said, "Well, why don't you take a look at this?" And at the same time I was thinking of, how did I do some functionality in SignIn.org? Because I looked at the whole rich conversation that GNAP has where GNAP starts off with a client talking to the authorization server. I realized, oh, I can layer what I'd like to do right into that. And that I can see how this simplifies a whole bunch of things. So at a high level, I was pretty excited with what he was doing. I've been pretty involved in IETF and have chaired a couple of different working groups. Justin had suggested that I co-chair the BoF, the Birds of a Feather, which is how you start up a working group in IETF. So I agreed to do that. And I co-chaired the first couple of meetings that we had and getting everybody interested in it. And because I was interested, I was out promoting it. And then I think that sort of helped that people didn't think it was just this crazy idea that Justin had, that somebody else that they respected was getting into it. And that I think helped build up a bunch of the sort of community and interest in it. And then of course, we had all kinds of exciting times and getting it all off the ground. As anything that's a new movement, everybody would like their special thing included in it. So there was a lot of churn on exactly what was in scope and what wasn't in scope. So I would say a lot of the flavor I wanted has been added into it.

Vittorio Bertocci: Let's add a bit of details to that. Like in practice, what does it mean? How did this interaction happen? You mentioned back there, you did a bird of a feather. This is basically a meeting that happened in the context of one of the biannual conferences of their IETF. Right? So it was like one room in one hotel in some city. Was it in Montreal, maybe?

Dick Hardt: It wasn't in Montreal. It was in Singapore.

Vittorio Bertocci: Well, okay. So in, Singapore, in the context of these mega meeting of IETF, in which people go and discuss the advancement of specific protocols, you had the bird of a feather in which people are intervened, how they got excited and then what happened, mailing list?

Dick Hardt: No. So actually a mailing list gets started so that the TX Auth list, the list still for GNAP is called TX Auth. So there was some discussion about that. Once you get enough people... few people subscribed to the list, then they'll call a BoF. And so I chaired the meeting, and what we did is we had a number of people present. There was a lot of debate. Should there be a new working group? Should this work be part of OAuth, wasn't clear how that should happen. And so my role was really to drive a lot of that conversation, to figure out what do the people involved want to do? Where should we do this? And what made the most sense?

Vittorio Bertocci: And the consensus was to create a new working group.

Dick Hardt: The consensus was to create a new group, yes. And part of the reason for that is the OAuth group already has two sessions at IETF, and there's all kinds of work happening there already. And so some brand new thing could be looked as super distracting for that. And where, if you are creating a new layer, why don't we create that in a new working group? So it's focused. And then the people that only care about the new work can subscribe to that list and the people that only care about all the stuff that's going to be practical in the near future, would be on the OAuth list. And the people with interested in both, can subscribe to both, right. But they can separate the topic instead of having them all on the same mailing list.

Vittorio Bertocci: And so, both the timescales are different that GNAP is future-looking, whereas OAuth is very much tactical for today. But also the other thing right there, I think is really important to mention is that the GNAP working group doesn't feel constrained by existing tech. You guys are going to produce something that doesn't have to inter operate with OAuth, right?

Dick Hardt: Correct. It doesn't need to be backwards compatible with OAuth through OpenID Connect. In the charter, we do want to make it easy for someone to migrate from those two platforms. But there's no requirement that it interoped, where anything happening in OAuth needs to have interoped in the OAuth working group with OAuth.

Vittorio Bertocci: That makes sense. So this is going to be today, I have all my appliances, in particular my hairdryer, we have the European flag, and the moment in which you move to the next step, the plugs are going to be different. So migration is possible. There shouldn't be any expectation that things talk to each other out of the box. If one is using OAuth era generation protocols versus GNAP era generation protocols.

Dick Hardt: Correct. But as you said, I can imagine that libraries would support both and that large authorization servers will support both. And that both protocols might be being used. I mean, one comparison is, OAuth is like what FTP was in the early days of the internet, that was the way to move around files. And then HTTP came out. You're still moving files around, but the model's different than it was in FTP. And so GNAP is kind of like the HTTP model, right?

Vittorio Bertocci: Thats right

Dick Hardt: But you could also compare the two of like HTTP and HTTP/2. HTTP/2 works differently than HTTP, right? It takes advantage of a bunch of other modern functionality. You're still moving things around, but there's different features you can do. So like anything, no analogy is perfect.

Vittorio Bertocci: Of course. I remember that there was one of the big discussions that I've observed in the list it was that there were two different drafts that were embodying the principles behind GNAP. You want to expand a bit on that?

Dick Hardt: Yes. There are two drafts. I looked at what Justin had written up and a lot of it was concept and some of it was specified. I had some different ideas around how to do some of those. And I thought that the best way of expressing those was to write a different draft. Justin gave me a bunch of feedback on that and I adjusted that draft a bunch. And then as I continued to work on it and think about it, the models I had evolved a whole bunch. Lately, the drafts there's some features of the drafts that have drifted a little bit closer together, but Justin has his opinions on how some things should happen. And I have some different opinions given that we both have significantly different experience around how to do some things. And so I think those two drafts are the basis for us to think about how do we go forward and look at which way on those things is potentially better overall. And that maps into the IETF rough consensus process. Which is, it may not work how you'd like it to work, but is it going to hurt you? Do you have an issue with it? It isn't that you get what you want. It's what you get will work for you. My undergrad was in mechanical engineering, so I am way more of a practical, how do I just get what I want to do done? I want people to easily understand what the heck's going on. He's much more of a computer scientist. And so some of his models are a little more pure from a model and conceptual point of view as to how he represents things. And to me, that wasn't as important to me. To me it was more around, well, what does somebody already know? And how do they map what they know to the protocol?

Vittorio Bertocci: Right. It makes a lot of sense, but well, the IETF process can sometimes be painful when you're trying to drive to the consensus. But ultimately I think with the result is usually good. That's to say that the process eventually makes bubble up the goodness of a specific idea. So I'm confident that the combination of these two camps. And I've seen lots of other contributors too, at least. So I'm confident that the end result will be good. This was a fantastic summary of how we ended up with the GNAP working group. Now I was wondering, can we dive in one of those specific scenarios, that are, let's say, GNAP exclusives, as in things that are hard or impossible to achieve with OAuth, but instead are very natural with GNAP.

Dick Hardt: Sure. Well, one of the caveats is that it wasn't clear to me how to put these features into OAuth. But it was clear, easy to for me to see how to do it in GNAP. And long- term it could be easy to back port these things to OAuth. The next thing is I probably need to provide some context about what is SignIn.org And what are we trying to do? The idea of SignIn.org is how do we solve the identity problem for consumers? How do we get consumers to have a provider so they can just log in once and they just pick one provider and they can log in everywhere? And one of the challenges in that is today, the developer picks which providers to show on their app. But what if we put an abstraction layer where developers used SignIn.org, and then the user could pick whichever provider they wanted, they could change providers. And so essentially that's what SignIn.org is. But since there's no users in SignIn.org right now, I wanted to have an easy mechanism for developers to incrementally support SignIn.org. And one way of doing that is that more and more applications are going where they ask the user to identify themselves first. They type in their email and then they get prompted for a password later. And that identifier first flow enables a site to have any kind of authentication mechanism they want. They're not asking for user name, password. Whatever the user gets prompted with is based off of the user after they've self-identified. If the user, in an enterprise case, maybe it bounces them over to their enterprise IDP. If the user's enabled, say FIDO Authentication, the user then gets prompted to touch FIDO. Or if they have a password, of course they're asked to supply their password. And so with that, I wanted to go and enable a site to go with that identifier, the email address to query SignIn.org to see is this user have an account at SignIn.org. And if so, you show the button only if the user has an account, or if you only want to use SignIn.org, if the user doesn't have an account, you explain what it is and that they will need to create an account over there. So the experience you show the user is dependent on whether or not that email address is in SignIn.org. And so I needed to have some API to query to see if you already have this user. And if that API is effectively part of the initial GNAP set up call, the app doesn't need to make another call if it does want to use SignIn.org. So it says," Here's what I would like from the user." The site can return back and says," Okay, this is how you can interact with the user." And" Yes, I've seen that user." Or" No, I've not seen that user." And then the app can decide, does it even show the SignIn.org button to users there? It just shows it. If not, they may not do anything. Or they may say," Okay, we only use SignIn.org." Or explains what it is so people understand why they're going to get sent over there. If they already have a SignIn.org account, they'll know what the button means when it shows up.

Vittorio Bertocci: That makes sense. And how does this project at the protocol level?

Dick Hardt: So this is in GNAP, right? You've got this rich request that the client is making. Saying there's a section for the client to identify itself, a section for the client to identify the user it thinks or knows that it's interacting with, a section to say what claims it would like to get about that user, and a section about what authorizations the client would like to have. And so it was really easy in this then to go and add the email identifier into this user section within GNAP, so that I got the results I wanted coming back. And so I've written that up as an advanced feature for GNAP because it's very easy to do because it just falls into the GNAP message format very easily. Where that doesn't really exist in OAuth today.

Vittorio Bertocci: I see now. So the fact that GNAP has a very rich structure for communicating through the authorization server the details of requests, but also other things like users and similar allowed you to carry that information. And I can see also what you were saying earlier, which is technically you could use PAR for shoving this information in the request, but the other part is like schema-free. Then it wouldn't be... It's technically possible, but it would not be as easy. You wouldn't have intellisense to use it. In developer terminology here.

Dick Hardt: Correct.

Vittorio Bertocci: That's really nice. And here, allow me to be done because also I can't help. You mentioned earlier something about the front channel and the fact that the front channel has lots of challenges, and the threat model associated with it is complicated. This scenario that you just described, I can imagine that happening on the browser. So their request that you are envisioning would be done, is it done from the browser to the authorization server of it on an interactive endpoint? I don't know what endpoints you have in GNAP, but in OAuth that would be the authorization endpoint. Or do we envision these requests to be done as in server to server, how would you avoid the front channel in that particular scenario?

Dick Hardt: Well if it's a browser-based app, it's just calling the GRANT server's endpoint directly. It's not redirecting the user through a browser page to the authorization server or OpenID provider. And so, that all is happening before the users even making a decision about what they want to do. The client is essentially doing a pre- flight and it might find out that it isn't able to do anything. And so it doesn't even bother the user. And OAuth, you essentially need to go and redirect the user over to the authorization server, but that client might not be allowed to do that at all. You don't know, you've had to send a user over there, that user's had to authenticate, just to have the authorization returned back and say," No, you're not allowed to do that."

Vittorio Bertocci: I see. So you'd have a client that, before rendering anything at all, would just hit your GRANT endpoint with the request. And then depending on what it gets back, it would decide to either render the button or not. These would allow you to do this regardless of your rendering engine. As in, if you are a web app, you do these in a web page. But if you are a mobile client, you can do exactly the same flow even if you don't have a browser available for doing very direct.

Dick Hardt: Right.

Vittorio Bertocci: Am I catching these in the right way?

Dick Hardt: Yes. And that ties into another aspect of GNAP Which is, there's another chunk called interaction. And so the client says, "If you need to interact, you..." The authorizations are a GRANT server in GNAP," need to interact with the user. Here's the ways that I can start off interacting with the user." And then the GRANT server can look at that list and decide which, if any, of those it wants, or if it even needs an interaction, and send that back to the client. And so, for example, one of the proof of concept apps I wrote was a little command- line utility that uses GNAP. That command- line utility creates its own public- private key pair that makes a call to the GRANT server and it gets back a result. And one of those results is a URL that could be rendered as a QR code. And then on the command- line, it just prints out that QR code. I can take my phone, scan that QR code, I pop into the authorization server, go through the regular authorization flow. And when I'm done my command- line tool now has a token for it to go and access whatever resources it was asking for, without... It's a very clean, simple experience, and you're enabling the client and the GRANT server to have that negotiation. Now today, people sort of bake that in to... this is exactly how this client's going to work, but you might have some optionality. So for example, the web app, it may be able to go and redirect to my authorization server. But if I've got a app on my phone that also represents my... It's an interface to my authorization server, might be a lot easier for me to scan a QR code on a webpage on my desktop to log in, than to go and have to fiddle around and figure out how do I authenticate to the authorization server and a webpage? Because I've already got this phone... Security on that might be a lot easier and a lot better. And so that enables not just the negotiation between the client and the GRANT server, but also between the client and the user as to what experience works better for the user.

Vittorio Bertocci: Great, fantastic. Again, trying to summarize and synthesize this scenario that you described. That are all scenarios that today, we achieve with the developer explicitly baking in the capability in their clients in advance. So, the scenario with the QR code there, you do it with OAuth2 device grant. The other scenario with the mobile app, you do the usual mobile tricks that we do today, the web app the same. But the point of GNAP is that you can negotiate those behaviors at runtime, as opposed to have to bake these in the design of your app.

Dick Hardt: Correct. Right. And provide that optionality to the user wherein general, today in OAuth, you pick one way, right? You can't really do multiple ways. And it also then has an extension point, as there's new interaction mechanisms come out, we can define those. And those can be negotiated without both the client and server having to deploy them at the same time. The client says," I'd like to do this." The server," I don't know what that is." And then when the server does know what it is, then it could be offered.

Vittorio Bertocci: That makes complete sense. Today my experience was... Especially when, back in the .NET days, .NET can run in so many different environments. And so your application might wake up on a device that has no browser at all. And then you need to have a big switch statement that says," If you wake up in this situation..." do the device. Well, if you wake up on a mobile environment where you have the same browser using a system browser, it was all codes that had to be written by the app. And instead, if we'd have these kind of a new protocol, then would perhaps be able to bake this into SDKs so that the developer doesn't really have to do the coding that they have to do today for differentiating between both scenarios.

Dick Hardt: Right.

Vittorio Bertocci: Fantastic, great. This is ultra interesting, but I'm keeping an eye on the clock and I see that we are nearing our limit. So let me try to summarize. GNAP presents a new approach to many of the things that OAuth and OpenID Connect have been doing today. It sheds a lot of the constraints that OAuth and OpenID Connect have because simply of their age. And so it allow you to achieve some of the scenario that we do today in a cleaner way. And so the resulting protocol is cleaner, the time horizon is still reasonably far, right? Like it's still pretty experimental.

Dick Hardt: It's definitely experimental. The time horizon, like any standard, OAuth took a couple of years to go through. And so a lot of that is just how well is the working group functioning and how well do we get to get to consensus? How much time do people need? And so GNAP may never emerge as a standard. It might be five years. It could be a year. But even when it's out, that doesn't mean people should stop using OAuth and OpenID Connect. It's just another tool in people's tool chest about what they could go and use.

Vittorio Bertocci: Wonderful. Fantastic. Thanks again, for taking the time to join us. It was a tour de force. I'm sure that lots and lots of people heard about GNAP, and will appreciate the clarity that you brought to the topic. I hope that you'll come back here on the show in the future because you are working on so many interesting things. You also mentioned OAuth2.1 and SignIn.org of course, I hope we will have more opportunities to feature you, but until then, thank you.

Dick Hardt: Thank you.

Vittorio Bertocci: 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 Woloski. Identity, Unlocked is powered by Auth0.