Browser Changes on Identity Protocols with Sam Goto and George Fletcher

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 specifications and trends from a developer perspective. Identity Unlocked is powered by Auth0. This season is sponsored by the OpenID Foundation. This is an unusual episode. We're not going to cover a specification. We will instead focus on a very important thing happening in our industry today. In a nutshell, browser vendors are working to offer better privacy guarantees to users and in so doing, they are removing some features and adding new ones. That activity is affecting how identity protocols work in the browser, making it necessary for providers, developers, and end- users to change their behavior to preserve existing scenarios. Things are still very much in flux and proved to have the potential to affect swiping changes touching everyone. So, I thought it would be interesting to invite on the show some of the protagonists involved in this work. Today we're chatting with Sam Goto, software engineer working on Google Chrome and George Fletcher, Identity Standards architect at Verizon who had been monitoring the events and with whom I have the pleasure of collaborating on a related initiative, which we will cover during the show. Welcome, Sam and George.

George Fletcher: Thank you, Vittorio.

Sam Goto: Thank you, Vittorio.

Vittorio Bertocci: Thanks for joining me today. As is tradition, we want to hear from you guys on how you ended up working in identity. Let's start with you, George. What's your story?

George Fletcher: Surprisingly enough, my very first development job out of college was really an identity project though I didn't know it at the time. 1996 at AOL. 25 years later, I'm actually still sort of at AOL, being that Verizon Media is the combination of AOL and Yahoo. In between there, I've done a stint with The Liberty Alliance. That was sort of when I got into identity full time, sat on the SAML SSTC for a little while and then got very involved in Open ID one, OAuth1, OAuth2, Open ID 2 and Open ID Connect. I'm now a community elected board member of the Open ID Foundation and as Vittorio said, I'm identity architect at Verizon Media. Finally, my statements today are my own and don't necessarily represent those of my employer. Thank you very much.

Vittorio Bertocci: Wonderful. That's always nice to clarify. Thank you, George. That's fantastic. You're one of the rare cases in which you have been in identity stably whereas others often tell stories of complete randomness and butterfly effect bringing them to identity. So, great. Sam, what about you? What trajectory did you follow to get to work on the identity features in Chrome?

Sam Goto: That's an interesting question. I have a background in compilers, computer architecture, hardware operating systems, so low level stuff and I got really, really tired to do hardware at some point in my life and I came into Google to do software which was an immense changing in my life. For the first few years, I've worked on consumer apps, so Orkut, Gmail, Google Docs and at some point, social. Then somewhere at that point, I transitioned to developer platforms. Since then, I've been doing developer platforms for Google Social and Google Search and now more recently, Chrome. My first point of contact with identity was when I was working in social at Google, to do one of the versions of Google signing. So, I was a tech lead for one of the versions of Google signing, arguably one of the least popular versions of Google signing. Then I did a stint at Google Search doing a lot of crawling of the web and more semantic web stuff which was a lot of fun too and now, at some point, I transitioned from a web app developer to crawler of the web to actually influencing the web and changing the web. So, I moved the web platform team inside of the Chrome team, still with a bit of compilers and computer architecture backgrounds and at some point, ran into identity as a good place with a lot of opportunities and challenges. Much like George, I speak for myself as opposed to my employer and my opinions are my own.

Vittorio Bertocci: Wonderful. Fantastic. It sounds like you touched on really, really consequential stuff so the fact that you chose to move toward identity is really nice. I'd say that whenever I read what you write, it's clear what you have is very formal approach, which the compiler background actually explains well. Okay, perfect. Thank you so much for sharing that with us. Let's jump straight into the topic and let's start with you, Sam. Can you tell me what is going on? What is the problem that moved the browser vendors to start considering those changes?

Sam Goto: The overall idea is that federation is pretty awesome, right? The federation is pretty good and at least compared to the alternative of user observed passwords. Pretty important and wonderful thing that has been part of the web for awhile and by design, federation was built on top of the web rather than into the web early on, which it was totally justifiable in the context that it was designed. I wouldn't be surprised if someone raised their hand and said, "Wow, let's work with the browser vendors." That would take a long time to develop federation, but it wasn't the case.

Vittorio Bertocci: Sam, you know that this is an identity show and our audience is probably going to be really particular about the use of terms, I guess when you say federation, you mean a way of outsourcing authentication to an entity which is not your app. The reason for clarifying is that very often in our space, federation is a very specific topology in which there is an Organization A, an Organization B, and the way which you get those two together is to use the federation protocols. You're fully justified in using the term the way you use it because most protocols might have been born for that topology, but then they are used also for scenarios where there is an Organization A, Organization B. It's just the way you're outsourcing authentication, but I just wanted to clarify that when you say federation, you mean not just SAML but also any mechanism in which you get redirected to different identity provider. Is that right?

Sam Goto: Well, to be very specific, by federation, we mean what you typically see in consumers. Things like sign- in with Google or login with Facebook. Unfortunately, part of the foundation that those protocols were built upon, namely low level primitives like third party cookies, iFrames, pop- ups and redirects is under a lot of pressure, largely because some of this is being abused to track users without their control. So, browsers are going through a reforming the foundation, I guess and it's really challenging. One of the reasons it's really a challenge to reform any foundation is because it's really hard to distinguish between the good users of the foundation versus the bad users of the foundation, right? When you can't distinguish between what's good and what's bad, you kind of have to apply the strictest common denominator, right? We've seen some of this earlier, before the pat when some of these user experiences used pop ups for example and pop ups started being abused, so browsers started to tighten up how pop ups are done and Open ID Connect and other protocols had to adjust to this new world. So, that leads us to the problem we've been calling the classification problem which is the browser's inability to distinguish between federation and uncontrolled tracking on the web. Now, I think the classification problem is something that is easy to grasp but when you're changing the foundation, I think you have to understand what are the fundamental problems that caused the old foundation to succumb so that if you build a new foundation, it doesn't go through the same profiles or doesn't incur in the same challenges and that leads us to the two other problems that we've been calling the relying party tracking problem and the identity provider tracking problem. Those are the three problems that we've been thinking about.

Vittorio Bertocci: I think I understood the classification problem, whihc is - those primitives are just neutral and can be used for good and bad... we assume federation is good, tracking is bad but you as a browser are in this difficult position of you need to prevent the bad and in so doing, you might be jeopardizing functionality. This is leading you to eliminate some of those primitives and then building new ones that will not suffer from the same problem. Then you mentioned there are two other problems like the relying party tracking problem and the identity provider tracking problem. Do you want to expand on those as well?

SAM GOTO: The classification problem is that these protocols are using low level primitives, so one of the easy ways out here is to build high level primitives, right? Identity specific primitives such that you have a very clear boundary and semantics about what's being done. One of the challenges here is that those high level primitives can also be abused. One can impersonate itself as an identity provider for example or one can impersonate itself as a relying party. So, the challenge here is what are the properties that these high level primitives need to have. So, one of the concrete examples here is the RP tracking problem is one in which by having these global identifiers being exchanged from identity providers to relying parties, it gives relying parties the ability to join users across different domains and in doing so, build a bigger profile without the users' necessarily consent. A good example is some of the big consumer IDPs that exist today, some of them return back to relying parties, global identifiers. These are numbers that are returned to the relying party that can be joined across relying parties, so when I go to one relying party and I sign in with my identity provider, if my identity provider is handing back to the relying party one identifier that is the same across my other users of other relying parties, then that can be used to join that usage and build a bigger profile of my usage of the web. So, one of the possibilities here without much loss of functionality is to offer direct identifiers, to shard identities across these relying parties, such that kind of by default, it's consequence free. But by default or there's no consequence in me sending a numeric number to one relying party and another numeric number to another relying party. That doesn't necessarily exclude the ability to offer with the user's control and the user's consent, to offer global identifiers but then it's just a matter of changing the defaults perhaps. You can address a lot of the problem by making the default easy and safe but the more challenging parts to be possible, but with more control.

VITTORIO BERTOCCI: That's very interesting. It sounds like the browser starting to look into aspects which traditionally are more on the identity provider side and relying party side instead now, in order to provide an extra layer of privacy, it looks like now you guys want to be involved in that aspect. That's very interesting. Now, if we just double click a bit and we look at the lower level, when we are talking about the features that are being discussed like the low level features which might change or disappear, what are the ones that are being affected both by things that we already saw playing out like same side and the things that you know are on the crosshair for being eliminated?

Sam Goto: There's a long answer and there's a short answer to this. There's a principle answer to this and there's a pragmatic answer to this, right? I think that the principle answer is written as... There's a good explainer out there called the privacy model for the web that explains some of the properties and the principles that form what the privacy model for the web could be and then those principles, they get materialized into concrete APIs or concrete affordances the browsers could expose that deviate from that principle.

Vittorio Bertocci: Who put this thing out, this explainer? Who wrote it?

Sam Goto: I believe Michael Clyburn from Chrome has written that explainer. I could be wrong. It is in his personal repo and I don't know exactly what stage it is at but it's the one that we use from a threat model perspective, from a principle perspective.

Vittorio Bertocci: I see. So, this is like the Chrome North Star. I say this as opposed to, for example, W3C or just for scoping the effort. This is a thing that you are using with the Chrome team as your threat model.

Sam Goto: Yeah. I don't want to overstate that this is something that the Chrome team uses generally. This is something that we've been using for our work specifically as the principal way to describe what the threat model is and what is the challenge, what properties a solution should have, what properties a name state should have. So, that's a very kind of instate North Star oriented document that goes over what the instate should look like and then you go one by one, more pragmatically looking at opportunities to go big bangs for the bucks. You know, there's some things that are easy, right? There's certain things that I think are overexposing you by default without necessity. I think one of the examples, I don't know if this is going to be a good example or not but sending cookies to images that are embedded on your website doesn't change that that's useful for a certain narrow amount of cases, but that seems that you get a big bang for the buck because image is mostly static, by making that more constrained. By changing the default, by default, you don't get to... You're making it private as opposed to where we are today, oversharing by default. Image links I think is a good example.

Vittorio Bertocci: So, let me make this more concrete. You mean that today, when you embed the image link, image source in your page, when the browser reaches out, if there is a cookie from a domain from where the image source is coming from, the cookie will be sent and you're saying this is one low hanging fruit in which we could prevent that behavior and then it will now be more secure, right?

Sam Goto: Yeah. I could be misrepresenting the same side to cookies meta model because I didn't push same side cookies myself but that to me as an end user seemed like an easy win. There's no reason why the server serving us the image needs to necessarily be told who I am or that I'm loading a specific web page.

Vittorio Bertocci: That's a perfect point because this is a great segue for me for moving this to George because in tradition protocols, say for example WS federation which is some people might call it a poor man's SAML but I hope that the wrong people don't hear me saying that. But in distributed sign out in WS federation was implemented exactly that way, in which you would have the identity provider that would serve a page, this page was a list of images and each of the sources of those images were actually on the applications that identity providers knew had this session built on top of that. So, the sign out was all those requests and of course, you wanted to add the cookie in there because if that indicated, yeah, this is the session that I want to terminate. I think this is the perfect incarnation of the conflict that we are in here, as in we all mean really good, you made an excellent description- You said Yeah, why would a user think this is oversharing? But from our side, as identity side, we relied on this. George, can we pick up on this and can you give me the identity side of the story? What's happening? How we are affected. What's your take on the things that we have been saying so far?

So, specifically on that one point, it is happening today with the Open ID Connect front channel log out. Front channel log out in Open ID Connect is broken by the most recent same side and other cookie changes. Not that those changes aren't good for their intended purpose but it does break and the unfortunate part from an identity perspective is the only way to solve that is redirect chains. Now, if the users only visited two or three sites for your IDP, that might work but redirect chains are really hard to get the user to stay long enough to actually complete, which probably means that some site at the end of the chain is orphaned. But that's about all you can do. Especially in the cross domain case, you run into this problem and many properties may have multiple of their sites running on domains that aren't the same as the IDP domain, even on reality it's known to be all one company, especially if you take language scenarios like example. IT and example. DE and IDP. example. com or whatever is trying to log them out. You're pretty much stuck with redirect chains today, so that's just sort of one example specifically to match to the cookie. I think the other thing that's important from an identity perspective is there are many use cases that are not just a consumer going and trying to access their reservation site via some shared IDP that they own. So, in addition to just sort of your standard web browser interactions, you've got mobile apps or desktop apps. So, fire up your Apple Mail app on an iMac and say, " I want to log in with...", pick your email provider. It's probably using Open ID Connect under the covers and that's being done in a constrained environment, so that changes the pattern at which... It actually makes a classification problem that you described earlier, Sam, a little bit harder because the browser hasn't loaded the relying party site and now the user clicked the login button, you're starting in the middle. Not literally the middle, but the mobile app is opening the system browser and saying go here and then when it's done, the redirect isn't a standard redirect to some domain necessarily. It could be back into the app. So, hopefully it would actually look a little bit like a URL because hopefully the mobile apps are using app links and universal links for their callbacks because there's lots of other security problems if they don't, but that's a different topic. That's another case, right? You have mobile apps versus desktop apps. You've got single page apps where the entire Java script is loaded into the browser as well as your sort of standard, " Hey, I go to Website X and I click the login button and it redirects me to the IDP I wanted to login from." I think one of the things is use cases. The other piece that I think comes into play here, not all of the time are the use cases around the user trying to login. The classic example for this is something like I go to LinkedIn and I want to find my friend, so I want to import my contacts from my email provider. There's no real login. I'm not logging in to LinkedIn, but I am leveraging the underlying protocols. Same principles, same impacts, to basically get an authorization. SAML in the university federations that Vittorio mentioned earlier often use basically unidentified authorization or they're anonymous SAML assertions that basically says Student A is a valid student at Stanford, so when they show up at the Carnegie Mellon online library, the assertion says nothing about who the user is, it's completely random and temporal but the authorization statement says their access. You have those kind of cases and then you have finally the kinds of cases where you're combining authentication and resource access at the same time. That's kind of back to that Apple Mail example where the mail client running on my Mac wants me to sort of login and get access to these resources. So, both pieces are involved in that process. I think we have to look at the entire scope of the kinds of use cases that we have when we start looking at these different problems. Specifically, I think classification is an interesting problem and your explainer does a good job at sort of showing different ways you could mediate that possibly once you detected it. Maybe there's some other things we could do on the classification problem. The RP collusion problem I think is a really, really hard problem for a browser to intermediate and that's because in many cases, if you think about the authorization code flow which I would argue is the most used Open ID Connect flow, there is no identity showing up in the browser at all. The only thing passing through the browser is the authorization code and the CSRF protection in the state parameter and then all of the data being transferred is back channel. That's done intentionally.

Vittorio Bertocci: This is a really good point. As in, some of the things that have been stated by Sam I believe are good things that we should aspire to but there might be things that are difficult to achieve, like the thing about the correlation as George just described. It might simply be something that a browser doesn't see and also there are other more mundane considerations as in I might not have a global identifier but if in both relying parties, I need to give my shipping address, then they are going to aggregate my information. Anyway, I can lawyer up and say, " Well, I didn't give you an identifier", but it definitely is something that even if you do everything you described, the browser cannot guarantee that this thing will not happen. That's fantastic and George, you gave a long list of really detailed situations where things break and we'll get back to it. But I wanted to go back to Sam for a second and talk about some of the features that are being added. I know that you guys in particular, as in on the Chrome side, you are thinking about adding new APIs that you hinted at that are specific for identity and as such, you will not suffer from the shortcomings and similar. We see that it might not cover all the things that George mentioned but I'd like to give you a chance to introduce it so that we can talk about those scenarios specifically.

Sam Goto: Yeah, the meta model is these protocols are using a lot of these low level primitives, so we're going one by one looking at the specific low level primitives that won't use this and then asking ourselves, what would a high level primitive look like instead? One could argue that using an image to check logout state from IDPs is what was available there, but what we're interested in offering, we're raising our hands and we're saying, " Look, that doesn't sound like its initial intended purpose, right? For the image tag. So, here, maybe this will be a better foundation to be at, right?" And arguably same with redirects or pop ups, right? A lot of these things were built on top of the web, not into the web and when you build on top of the web, like I said earlier, you have to abide to the lowest common denominator, what gets most of use on the web. So, the meta-process is that. Let's look at one by one the things that these identity protocols depend on and let's offer something that is high level and intentional and deliberate for it to be building up a stronger foundation or at least... The trade off here is between generality with overtness, right? That there's a reason why these low level primitives are compelling in that they are general. Right? They're general purpose primitives. They're Lego building blocks and they solve a massive amount of problems, right? So, they're very general but that's the trade off. When it's general, the policies, you apply them to the one that is the strictest, where the high level primitives are less general. You don't get to do arbitrary things with them but possibly the premise is that perhaps they can be more specific and more controlled.

Vittorio Bertocci: Absolutely. I don't think anyone would argue against that. In fact, I think a lot of people lamented the lack identity layer of internet for decades. So, the fact that someone is now working on it is fantastic but I think in this particular case, the devil is in the details. As in, these high level primitives of course by their nature, as you described, are coarse grained hence not as expressive but I think that we need to find where that line is because those things now make it impossible to perform some scenarios that today are fundamental for businesses out there. Then I think you'll get some pushback. Okay, can you go a bit more into the specifics of what Web ID is as it exists today does? What are the high level primitives that they are offering?

SAM GOTO: In our exploration of the low level primitives, we see that Open ID Connect and SAML depend on things like redirects, pop up messages, pop up windows, iFrames, and then communication across origins, across sites. When you have an iFrame, for example, for button personalization for example, when you see a login with X button and it contains your face in it, it's because they are using an iFrame and it's using third party cookies and it's personalized based on your login state with the IDP. But that also enables the IDP to be where you're going on page load. So for example, iFrames, the folks are looking into find ways to preserve that use case but make it more private. There are two variations that I think are interesting. One is called a fenced frame, which is a more private version of an iFrame, more constrained but sort of looks like an iFrame. It constrains post messages for example, communication of upwards and downwards. We have been looking at an identity specific native experience to fulfill some of the iFrame use cases. Exactly what that looks like, largely TBD but that's one of the use cases. Pop up messages too, we know that open pop up messages is something that identity providers use and post message to communicate between one another. So, we're looking at what is specific in the communication that's happen for what reasons and what that communication happens and what subset of that communication is safe or how can we make that communication such that you're revealing information to the IDP or the RP in a controlled fashion or with user awareness or control. The other use case here too is also redirects, right? Redirect, I think more fundamentally breaks these protocols so we're looking at ways to make that more controlled to. I buy very much the argument about there's a lot of stuff that needs to be done and it's hard to catch everything. My meta model has been that let's look at the things that gives us the biggest bank for the buck and make that as consequence free as possible, as safe as possible, to make disclosure of information as progressive as possible and as minimal as possible and then some of the things that are scarier or the things that we expect to be less common perhaps. There needs to be a catchall escape hatch that allows all to be done but perhaps that's where we apply more user control or more user friction so that it's still possible but perhaps with higher friction. Exactly finding that line, that balance, it's extremely hard, extremely difficult like you said and we don't expect it to be done over a weekend project because it's something that we're going to be working a lot with identity providers, the identity ecosystem, relying parties and trying to strike the right balance.

Vittorio Bertocci: That makes a lot of sense. Just for our listeners, WebID right now is largely an initiative driven by Google. Do you know if other browsers are considering adopting it as well?

Sam Goto: It's been largely an open and transparent public project right now. It is fair to say that it's permanently driven by Google but it has been fairly open, so we have a lot of browser engineers who jump in and participate in these discussions publicly. We have identity providers who show up and say, " This won't work because XYZ," or, " Ugh, Sam, you're only consumer oriented. You have to pay attention to this allocation or enterprise space here that you're ignoring", which is much, much welcome, right? It's very much interested in hearing a lot of this. We know a few things, right? We know what individually can solve this problem, but there isn't a single entity or person that can solve this problem in isolation and too that it will take a long time to solve it. We've been very open and transparent and public about this early on, which is sometimes in tension with clarity and concisiveness, right? You probably see our explainer is super long. The reason it's super long is because it's early and we're intentionally confused and we want to learn, because if it was short, it was because we had already formed an opinion. It's long and confusing because we're inviting the discussion and our narrative is almost along the lines of here are the alternatives, here is the options and we don't know exactly which ones are the best but we are inviting the folks for having that conversation so that we can understand what works best.

Vittorio Bertocci: That makes complete sense. You are absolutely right, the problem is intrinsically complex, multi-parts and similar. The thing that can inject a bit of urgency is that occasionally people hear Feature X will be discontinued by Year Y and so, that somehow puts a spring in their step so when they go to meetings saying, " What do we need to change and by when do we need to change it in our product?" Which brings me back to George. George, what's the stance that you observe in the identity space about the initiatives like Web ID? What's the atmosphere there?

I think there's probably a little bit mixed in the context of support and agreement and concern. Some of the initial views into it look like a completely different protocol, so that sort of means IDPs have to change, relying parties have to change and that always causes all of us concern, especially manager support, both relying parties and identity providers. But at the same time, I think there's a desire to also work with the browser manufacturers on the effort. I don't think anybody's against... We shouldn't protect users' privacy. In that sense, I kind of feel like I think sometimes in looking at these problems, because you've done a really good job sort of articulating what the problems are, maybe looking at them individually, even though we're looking for a holistic solution but looking at them individually, we may be able to do things. The updated explainer with the classification problem, I think separating ad tracking or bounce tracking from identity flows and the browsers doing something about that, but letting the rest of the protocol continue as is, I think would be a huge step forward from a privacy perspective with potentially no impacts on relying parties. There is a potential for friction. I agree with your sort of analysis and explainer around where the browser might have to do interstitials but in reality, in most cases, I think those could be one time. The very first time I'm using the browser and I'm going to my IDP and the browser comes up and says, " Do you really want to log in with this provider?", and I say yes and it can remember that. To me, that is reasonable friction to protect the user's privacy with minimal impact to the downstream systems. Maybe we can tackle that problem and get something around that out sooner. And the RP classification problem I think is going to be really, really hard for browsers to actually solve unless the browser, and Vittorio may not agree with me here, but unless the browsers adopt some sort of decentralized identity model and champion it because then the browsers are in control of the attributes that are being shared, at which point the whole underlying protocols are gone anyway. But you do have control, but specifically in the RP problem, I'm not sure it's a solvable problem, especially when you talk about code flow. The final thing I will add into the RP that Vittorio referenced in the sense of shipping addresses is all relying parties must have an identity model that they support. They may not do authentication. They may even in some cases kind of outsource the recovery but fundamentally, if I'm a relying party and I'm offering a consumer a service, especially if it's a paid service, there must be a way for that user to use my paid service even if something happens to the identity provider, which means I have an identity model, which means I need recovery, which means I need all these other things. As soon as you pull in things like recovery, you're going to get a real email address or a real phone number which are the global correlatable identifiers that are most often used, unfortunately from a backend tracking perspective. Again, all of those things together for me would say separating out the RP problem from some of these other problems is useful. Not that we can't go after it but to separate it out because it's a way harder problem to solve given the ecosystems that we have today.

Vittorio Bertocci: Thanks, George. This is super comprehensive and I think the meta point is the discussion is still very much ongoing. So, clearly I think that the action from this has to be: "this thing needs to happen and it's going to affect everyone. So, I think that it's in everyone's interest to contribute their point of view so that we can do what we can to steer". Before we get to the call to action, I just want to clarify. It's not that I'm against decentralized. I'm against decentralized without a use case, just as a principle, like the ten tablets coming down from the mountain. That is the thing that I'm allergic to. But for places where there is a clear use case, like for example solving the relying party problem, I am happy to dust off my Cardspace book that I wrote a decade ago and the reapply all the same principles. So, this was absolutely fantastic. Can you each give me a call to action? George, what's the thing that you want our audience to do after listening to you?

George Fletcher: My call to action is participate. Get involved in the conversation, share your use cases, share the places where current browser changes made in good faith have affected your deployments, all of those kinds of things because I think we need a much larger group of people in the conversation. That's my thing. Participate. There's the WC3 privacy community group where some of this stuff happens. There's the WC3 incubator community group where Web ID is... There's many Github repositories and I'll let you talk about the browser use cases one, Vittorio but really just participate. I think it's awesome that Sam and the Web ID community have been very open to participation. Let's get involved because I think the privacy problems are useful to solve, but let's solve them in a way that we don't break substantial deployments across the web.

Vittorio Bertocci: Thanks, George and to add details to the GitHub thing that you mentioned. George and myself are working with IETF to catalog all the scenarios that use some identity protocol that are in current use today so that we can have a solid artifact to use during discussions so that when a change in a browser risks breaking something, we can pinpoint what it breaks and what are the consequences. We are gathering those scenarios, we devised a mechanism for people to easily contribute to those and I'll add the link to the show notes. Sam, same question for you. What's the call to action that you want to issue?

Sam Goto: I think participate is a good call to action indeed and I would encourage everybody to participate and come. It's a really hard problem. There isn't anyone that can solve this individually and specifically ourselves, right? We are browser engineers writing C ++ code. Some of us have some identity experience but look, there's Open ID Foundation with a massive amount of information, of knowledge. There's the SAML community, massive amount of information. There's a privacy interest group, committee group with a good amount of information too. There isn't a single group that holds all of it, so just come but I would encourage you to set your mindset to just assume that there isn't any easy solution. There isn't any simple let's get it done and implement the spec and you'll be done solution. So, come with an open mind, focus on problems. One of the reasons why I love talking to George and Vittorio is because we always talk a lot about problems rather than specific solutions and we always talk about the solutions in terms of alternatives and trade offs, not in a dogmatic way about we shall do XYZ, right? A lot of these are discussed. There isn't a win- win that is a perfect solution and I think having that open mind about changing your mind about some of the early conceptions that you had is extremely important to us. So yeah, participate I think is a good call to action. There's a tension between early and being concise and clear, so just understand that there's a lot of... We're going to have to find ways to make this constructive and objective and productive and I think the work that you've been doing with the use cases, with working group and Open ID Foundation is just a wonderful way to participate constructively and objectively rather than defensively. We're taking that very seriously and we love that effort and we want to see more of that.

Vittorio Bertocci: Wonderful. Thank you so much both. This was an extraordinarily interesting episode and I believe that the community will have to work together on this for a long time, so I'm looking forward to see how people will react and follow up and contribute. So, thanks again and thanks for being a guest on the show and for your time today.

George Fletcher: Thank you very much. This was a lot of fun.

Sam Goto: Thank you. It was a lot of fun.

Vittorio Bertocci: And thanks everyone for tuning in. Until the next time. The Open ID Foundation is a proud sponsor of the Identity Unlocked podcast. Since its formation in 2007, the foundation has committed to promoting, protecting, and advancing the Open ID community and technologies. Please consider joining the foundation and contributing to current working groups. To learn more about the OIDF, please visit www. openid. net. 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 Wilowski. Identity Unlocked is powered by Auth0, copyright 2020, Auth0 Incorporated, all rights reserved.