Continuous Access Evaluation Protocol (CAEP) with Tim Cappalli and Atul Tulshibagwale

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. In this episode, we focus on the work of a shared signal and event working group in the OpenID Foundation, and in particular, on the continuous access evaluation protocol. Today, we are doing something new. We are welcoming two guests. Tim Cappalli, Digital Identity Standards Architect from Microsoft and Atul Tulshibagwale, software engineer from Google. They're both closely involved in the working group activities. Welcome guys.

Atul Tulshibagwale: Thank you.

Tim Cappalli: Thanks Vittorio.

Vittorio Bertocci: All right. As it's tradition, let's start with how you ended up working in identity. Tim, let's start with you.

Tim Cappalli: So I have a quite an interesting path to where I am. I went to school for photojournalism and TV directing and sports directing, but during that time I worked about halftime probably too much for being also in school as a network administrator for my college, which was a small one up in Vermont, not a lot of staff. So I was able to jump in and get a lot of experience, that was right when wifi really became very widespread on like a college campus or an enterprise. So a lot to learn. I kind of quickly became the expert because I was actually the one touching it. After graduation, I went into TV for a little bit. I had been interning and working over the summer at some TV stations in Providence directing. Realized automation and it wasn't the old school TV newsroom, where there was a hundred people and everyone working together, a lot more automation and all that fun stuff. So I kind of saw the writing on the wall, ended up going back to where I went to school to finish the wireless rollout, to start rolling out the value added services to students like being able to use their brand new Google Home or Apple TV in their dorm room, which was very challenging at the time. So I stayed there for about a year and a half and then moved back to Massachusetts and worked at Brandeis University and took over. That was really my first true forte full- time into the identity space, but it was on the network identities front. So a brand new network access control has been around for years, but it never really, it was always a kind of a miserable thing, nobody really liked it. And this was the first step in really adding role- based access and firewall policy and really dynamic identity to the network side, right? Generally a wired port you just plug in and get on. And on the wireless side, people connected to a really unsecure network and then VPN, right, it was just a terrible experience. So, that's really where I dove head first into at the time it was a new product that really went into kind of this, if this, then that style policy with rich context connected to generic LDAP active directory could do single sign on all these cool fun, not necessarily new protocols, but new to the network space. You generally didn't interact with those. So I did that for about two years, then moved on to a partner of essentially the company that provided this product and essentially did all of that type of work for a ton of customers around the country as the essentially led their mobility and access solutions group. And then I actually went to work for the vendor, right? So I went to the dark side, stepped over and started working for the company who made those products and that my partner sold. And over the course of about five years, right before I left, I essentially was the identity architect for the security group. And we were really working on everything from cloud- based network security on edge network access to what can, really that the goal is this kind of edge compute and how users access the edge network with starting to get into 5G and federated wifi roaming. So really my last big thing was federated wifi roaming, and came to Microsoft and saw a lot of things around decentralized identity that could play into federated wifi roaming, and started to leverage a lot of those technologies at Microsoft.

Vittorio Bertocci: Oh, wow. Very interesting trajectory going from TV to decentralized identity. I'm not sure if everyone would say that you got in a better place, but I'll leave it to our listeners to judge. Thank you. It was really fascinating. What about you Atul, what's your story?

Atul Tulshibagwale: Yeah, so my story is a rather different, I got interested in public key cryptography just as an academic curiosity. I was studying computer science, but it had nothing to do with the coursework I had. So I found a job in India for doing some PKI based antivirus prevention, way back. And then at that time, America wouldn't export the crypto toolkit to India and so they had to get some clearance to get me here. That's how I ended up in identity. I was very interested in this notion of certificate authorities. And so I found Verisign it was very early. And then I joined Verisign as one of the first few engineers there. That's where my identity journey began. So I started with working on the S/MIME standard for email, then also code signing certificates and the OCSB standard. That's where the federated identity stuff started picking up. And I was one of the first people in the Liberty Alliance standard. I was representing Verisign. We did a lot of work there, which was then consumed into the SAML spec, the SAML 2.0 spec. And I started my own company at that time called Trust Genics we created the notion of a federation server, which was then copied by a lot of vendors. And we also contributed to the SAML 2.0 spec and then eventually our company was acquired by HP and then I decided to go away from identity at that point, but that didn't last very long. I came back and I am now working on identity at Google. I'm very interested in this decentralized federated kind of identity.

Vittorio Bertocci: Great. Thank you. This is like a very, it like you have a very solid classic approach as in starting from PKI and the good old federation SAML and similar so, I guess when you say decentralized, you don't mean decentralized in the same shade of semantic that Tim uses, as in actually- they're like classic decentralization rather that.

Atul Tulshibagwale: Yeah. We're not there yet. So yeah.

Vittorio Bertocci: That's great. That's fantastic. Thank you. I love how different your trajectories were and you both landed exactly on the topic that we want to talk about today, which again is the working group for shared signals. So you guys choose who wants to lead- I'll just throw my questions out there and you guys speak it in whatever way you want. So I would suggest that we start with thinking about the problem that the working group is trying to solve. So what's the charter like how these things came to be?

Atul Tulshibagwale: A couple of years back, we started thinking about how the identity landscape has changed. We were in federated identity for some time now where you have an identity provider that could be your employer, who authenticates you and then you log in using that credential to a service provider which could be like a customer relationship management site or something like that. It was great in the browser world where you were sitting at a PC and your properties were not going to change for the duration of what was typically referred to as the federation session, which is you open your browser, you go to the website and you close your browser, right? Now, we're in a world where these sessions so- called can last forever. People are using them from various devices that move about, their environments can change. So I may be sitting at a private location in the corporate office or in my home. I pick up my laptop and I go to a Starbucks and now all of a sudden, my access properties are different, right? How do you deal with these changing properties? So obviously you have to adjust the level of access continuously as you go. And that's how we came up with this notion of the continuous access evaluation protocol, which was published in a blog by Google and in February 2019. And then suddenly we talked to so many people who all said that they were thinking about the same problem. We got together and we tried to formulate a way in which we can solve this using a published and subscribed method, which was sort of described in blog. And then we were doing this outside the auspices of any particular standards body to begin with. But then we found out that there is a related work going on in the OpenID Foundation called RISC. It was about mitigating catastrophic account compromise. So let's say somebody tries to compromise a Google account. Then maybe that person's Facebook account is also going to get compromised. And so we need to alert all the other providers who share the same user that there is some kind of account compromise attempt going on. So that was work which has already been done in the OpenID Foundation. Which relied on similar processes, although the problem they are trying to solve is different. And so as a result, we came together, we formed the new merged group, which is the Shared Signals and Events Group, which now subsumes both the RISC and the Cape efforts.

Vittorio Bertocci: Fantastic. Thank you. That's a great summary of how this stuff came to be. And so who's involved at this point, like who are the main actors that are contributing to the working group?

Tim Cappalli: Yeah I can take that one. What we learned over the course of those first, let's say two years was how many different people would be interested in getting a volunteer, how many different components of a network or an identity system would be involved? That's actually how I got involved when I was still working for a network infrastructure company. We saw that there was so much context out there and an identity platform only has a limited view. Weirdly we ended up with, I was representing kind of the network infrastructure side at the time we had traditional MFA providers, CRMs customer relationship management. And then we had mobile app security companies, right? Not quite MDM, but those little agents that sit on top. There was all this context out there and all of these different companies came together with very different views, but some common goals, which really the big one was contact sharing. A big piece of that context sharing is translation as well. A network session has very little in common with a federated identity session, right? They're just... they're not, the identifiers are different. The lifetime of that session are different. The credentials are drastically different. And so that was really a big piece is, how do we bring that together and abstract out some of the complexity that allow an event, let's say, so an event about a session or back to Atul's, coffee shop use case that user moving from an enterprise campus to their house, to a coffee shop. How do we provide that information in a way that each of the components can understand it? And that's really, I think how we got such a diverse group of companies and people together to tackle this problem.

Vittorio Bertocci: Can you mention some names like you represent Microsoft, Atul represents Google, what are the other recognizable names are active in that space?

Tim Cappalli: Yeah. So we have SailPoint, AWS, Lookout, Target, Telus, Salesforce, Cisco, and there's more than that, but it's a pretty wide and very diverse group.

Vittorio Bertocci: It's a very diverse group for sure. It totally reflects what you were saying about how heterogenous things are when you're trying to keep track of what happens across multiple mediums. So do you have a dependencies from other standard groups? Like you mentioned that you found a home and they OpenID Foundation, but I think there's something about OAuth as well?

Atul Tulshibagwale: So dependencies wise, I think our primary dependencies on this standard called the security event tokens, right? So these are signed JWTs that are JSON Web Tokens, which are exchanged between parties to convey events, right? So it could be any kind of event, but we are specifically using it for access related events. So that's the primary dependency is on the security event tokens.

Vittorio Bertocci: So you use the format that Sec defined to carry your own type of messages.

Atul Tulshibagwale: Correct, correct. So it's a discreet packet we just signed, which is sent across. So it's rather than a continuous stream, it's like these discreet tokens that get sent across. And then within the security events group in the IETF Note, SATs as they are called as a IETF standard and within that same group now that is a new draft being created, which is called the Subject Identifiers Graph. So, what it says is how do you identify, how do you describe who that event is about or the subjects in that event, how do you describe them, that is defined that this subject identifier as draft that is still under development, but that is which used to be a part of the RISC standard now is move to the IETF. And now we are depending on that standard.

Vittorio Bertocci: And is it already adopted draft in the working group? Or is it an individual draft?

Atul Tulshibagwale: It's still at an individual state, there's some discussion going on right now. It's very close to being adopted, but it's-

Vittorio Bertocci: I specify this because the podcast lives for a long time for things that can be changing adjustments to make sure that the listeners know that things are still in flux.

Atul Tulshibagwale: Yeah. Now there are some things in the specification that are specific to OAuth, but we don't think OAuth is a dependency as such on the standard, it's something that can help clarify maybe the sign out behavior in OAuth or things like that.

Vittorio Bertocci: I see. Tim, do you want to add something?

Tim Cappalli: Yeah. And I think when we first started this work, right, there was a heavy focus originally on access tokens, refresh tokens, ID tokens, SAML assertions, right? That was definitely the heavy... a heavy focus. And then as we started to look at all those other pieces of context, we realize a SAML assertion has no relationship to a network session. And I think the subject identifiers work really addressed the very focused identifier piece. And this work, we spent countless number of meetings over the past year, trying to talk about less specific identifiers because these disparate platforms may not use a common identifier. And so that was a lot of work and thats, that was my first real big, we had a lot of, lot of debate on that topic, both inside and outside the group. And the other thing I want to mention while it's not a dependency on another standards group, at Microsoft we see CAEP and SSE becoming part of kind of a trifecta of specs. If you're not familiar with FastFed, FastFed is a great way to essentially easily federate systems, ideally in a one- click button.

Vittorio Bertocci: We are going to have an episode on FastFed this season.

Tim Cappalli: Awesome, sweet. The other one is a SCIM, which is really designed to provision and deprovision users automagically, right? So traditionally, when you logged into a system, you could actually create the users in real time, but they don't necessarily have direct policy attached or direct context attached on. And SCIM allows that to essentially sync from your main central identity provider down to an application. So we actually see CAEP and SSE becoming part of that triangle, both FastFed could provision this and set up CAEP. And it really serves as the intermediary between SCIM provisioning and de- provisioning events, right? Because SCIM is really good at the start and really good at the end. And some basic changes like groups, but it's not really... it doesn't really address session control. So we really see these as really working together, hopefully in a really easy way to set up, one click ideal, and then providing all of that flexibility, like longer token lifetimes and things like location changes and all these, all these various sessions specific things.

Vittorio Bertocci: Interesting, interesting. That makes a lot of sense, yes. They do seem to go together. Fantastic. Great. So this is a great great intro to the topic. Now let's dig a bit deeper and in particular, let's focus on CAEP, can we start like I to see like what's inside, what it defines, how is it structured?

Atul Tulshibagwale: You can think about it as one part of CAEP is all about, or in general shared signals, not just CAEP the shared signals and events standard, which applies equally to RISC and to CAEP. It defines sort of a management API of how you start and stop a stream of events between a publisher and a subscriber. The central topic within CAEP is make a publisher and a subscriber. So somebody who knows something new about a user or a device or some shared state between enterprises can use an event stream between the publisher and anyone who's interested, which is a subscriber to send those messages. And that is a management part, which is how do you set up that stream? How do you update that stream? How do you express interest in certain resources and a certain the same? That is one part. The second part is it defines sort of event types. Like what are the different events that constitute updates? So take for example, let's say a location change, is a change of a property of a session and so that can be conveyed as a event from one publisher to another subscriber. Then there is obviously the subject types that we talked about, the subject type spec in the IETF defines certain subject types and share signals and event spec actually adds a few subject types to that, which are specific to the RISC and CAEP use cases. But in general, the shared signals use cases.

Vittorio Bertocci: So digging a bit deeper. I think I got the general intent. There's like a specific things that have changed and one place needs to be notified in another place. In practice, and you mentioned that there is a message format that the spec defined, but in practice, how does it happen? Like, do you define new endpoints, which are not in other specs? How does it happen? What's the mechanical aspect of it.

Atul Tulshibagwale: The spec itself defines a sort of a metadata, which is available at a single endpoint, right? And then you can pick up that metadata and then you know where to send the request to add a subject or to remove a subject, things like that.

Vittorio Bertocci: Is it an automatic data format or did you piggy back on discovery on OpenID or other existing metadata formats?

Atul Tulshibagwale: It's our own. But it's something that is being discussed as being something that can be taken out of the SSE spec and put in the SEC events working group in the IETF, it's called management API is what we're trying to call it. So it's not just on format, it's also like how do you start and stop a stream of events? Or how do you change the membership of that stream? Which means do I want to know about this particular user or this group of users or this grouping of subjects? So like for example, if there are two hosts, let's say just as an example, there's Google and there's Microsoft and Microsoft is the identity provider and Google is the service provider. Then can Microsoft tell Google that now we are going to start sending you events about this customer that we share, then we can expect the events to flow for all of those users of belonging to that customer. So that is one aspect of it. Now if you just open up a particular token, what you'll find is the subject type claims, like who is the event about, and then you'll find the event type itself. Like what does this event signify and then parameters that are specific to that event. So for example, you may say that is a level of assurance change, right? So what was a session that was private? It can now be considered public because it is in a public setting, right? So, that could be a part of a level of assurance change. Or there could be a credential change event, which is like, I've changed my password. The event generator said, Oh, now this user's password has changed. The service provider can say, okay, if the user's password has changed, my policy dictates that the user needs re- login. And so the service provider can take action based on that. I'm not sure actually answered your question.

Vittorio Bertocci: No, it does. Absolutely. So let me try to summarize to see if I understood. So, basically in the spec you have: message formats, entities that can be interested in a particular changes, a way of establishing like subscribing to particular events, particular changes, and then the endpoints will come into play in order to have the event sources and have it sync. You start actually with a metadata which is, I guess, how to advertise the various potential actors or how all this stuff works. Is it a fair summary?

Atul Tulshibagwale: That's a good summary. Yeah.

Vittorio Bertocci: Okay, great. Fantastic. So now just to make this a bit more practical. Can you think of some of the most canonical scenarios, where this thing would be useful? Like some high level scenario, which like some setup in which there are two providers and is the user and what might be used with CAEP to model these scenarios.

Tim Cappalli: There's two big ones that come to mind. And I think these really were the use cases that kind of started the work. One, I think Atul alluded to it was the location change. I think prior to having something like CAEP, I think the default behavior as implementers is to just reissue a token or request a new token, right? Location as an example may be context that's provided in a token, but the identity provider may not necessarily have policy around location. So to mint a new token, just because of location changes, doesn't always make sense, right? That could be an in-session update that will be updated again when a new token is actually needed for another purpose. So moving from a trusted, even from a VPN link to an open coffee shop network, or probably the more realistic would be when you're on a, maybe not realistic these days, but when you're in an office and move to a coffee shop, I guess both aren't realistic, right now.

Vittorio Bertocci: Our ancestors were used to go to an office and had this scenario. But in modern times we no longer do it.

Tim Cappalli: Right? Someday, yeah. That's a great example of many could view that as wasteful to continue minting new tokens. And it could actually be intrusive to the user depending on how that was implemented by both the IDP and the relying party and along those lines. And the other use case, which was really why Microsoft got involved was really being able to use longer tokens, but still be able to revoke a session in real time. Traditionally Microsoft services had an hour long access token services that are actually CAEP aware, can now get a 24 hour access token because we know that if the session is revoked, the client obviously has to be capable, which is a little play on the word. They will revoke the session and send the user or the device back to the identity provider. So that was a really big one. There really wasn't this concept of a real- time session revocation that could be fairly universally implemented.

Vittorio Bertocci: I see. Can you think of a practical scenario in which these things would happen? Like say that, I signed in with my identity provider and then I started using an app which calls web services, what could trigger this flow that you described?

Tim Cappalli: The one that we see quite a bit these days is the user going into a portal and saying, I think something happened to one of my devices, or I think my session's compromised. That's kind of the end user scenario. You have the administrator scenario where based on, let's say other telemetry, they think the users compromised, they may want to force the session to revoke to across all providers and send the user back. Or it could be more of a automated flow, like a device going out of compliance, right? The device going out of compliance was actually a huge source of conversation around what does a subject mean, right? Because we need to convey this user on this device, not this device and just this user. It needs to be that combination. And so that was another very common use case because there's tons of communications that happen back and forth between, let's say a mobile device management platform and identity provider on a regular basis. Devices are constantly coming in and going out of compliance.

Vittorio Bertocci: I see, that makes sense. Well, this sounds like a sign out in steroids. If we'd just have cookies, then you're the just fan out your happy sign out and you'd be fine. But here, given what you said about different artifacts- access tokens, tickets and friends, then a more genetic mechanism works. I remember one OpenID Connect workshop sometime ago in which you have a scenario that I found fascinating, you tell me if it's the one that applies here as well. It was: someone who has a Gmail inbox and they're using as a password recovery an hotmail inbox. Well, these days is Outlook. com. Sorry, I'm old. The idea was that say that the user does something wrong with OneDrive. And so their account gets revoked. And so now, their Outlook.com account is revoked or disabled. And now gmail needs to know because that user no longer has a recovery option. Is it something that a CAEP would cover?

Atul Tulshibagwale: Yeah, that should be possible with CAEP because when the event occurs that they have to revoke access, they can notify using CAEP that such an event has actually occurred. And if Gmail is one of the interested parties as a subscriber, they will get the event and they will take appropriate action and solves.

Vittorio Bertocci: Yeah. I'm not saying that your guys are saying CAEP and I keep saying CAEP that's because I'm Italian, I promise I'll try to say CAEP from now on. So CAEP.

Tim Cappalli: Yeah. And I would just add, right. I think one of the interesting questions that we get quite a bit, even internally at some of our companies is, where is the line between what CAEP is for and what RISC is for. And I think that's something that you, that scenario you just highlight probably leans a little bit more into RISC, right? Because we see CAEP is more of this kind of real time messaging about kind of normal events, a session revocation while it is somewhat extreme. It is a regular event that would happen across some type of messaging fabric, but an account takeover or credential compromise. Those tend to be more 911 style scenarios where RISC may be appropriate. And it really just depends on the event types, right? I think that's where the line gets loosely drawn of which of the two specs to find the event type that applies.

Vittorio Bertocci: I see. So CAEP is business as usual and RISC is the nuclear option.

Tim Cappalli: Right. It's loose enough that if there's an event type, that makes sense for your use case that's in CAEP and you treat it as 911. I mean, it really depends. I think that's the flexibility and all of these different network access VPN, SAML, OAuth, right? It's all really about the understanding of the two parties and how they relay that information.

Vittorio Bertocci: So let's be practical. Let's say that someone eventually creates an SDK that supports this stuff. Would these SDK in your view, support both RISC and CAEP? It's just like would pick what's appropriate depending on the event and similar, or do you envision two different SDKs, one for RISC, and then the other for CAEP?

Atul Tulshibagwale: I think from a publishing point of view, they may be different because the systems that may generate these events may be different. But from a subscribing point of view, I can see that they could be the same because you have to take overlapping actions and the resources that you are trying to protect. Maybe the same.

Vittorio Bertocci: As a potential implementer, I implore you guys from a working group to look for opportunities that make me work less. So if most things are both events sync and event sources, and the main changes are the nature of event, if we manage to have one single code base, I will be eternally grateful. I'm just throwing that out there.

Atul Tulshibagwale: That's great.

Vittorio Bertocci: Great, good. Thank you. I feel heard. So where are we on the standardization path?

Atul Tulshibagwale: I think where we are right now is you've had a lot of discussion like them a little bit too, which is we've beaten some topics to death we believe. And so within the working group right now arrived at consensus on like pretty much everything. And so the next step for us is to, we are working on this branch of the spec and we want to merge it to the main repository. And then in my comments from outside the working group. So people who are not active on the working group on a day- to- day basis, this might be a good time. Once we merged the spec into the master, that might be a good time for everyone to start commenting on it. And then we would request the committee to vote and ratify the specification after that.

Vittorio Bertocci: That's fantastic. If you have links that we can use for inviting participations I think that's great, this is a great call to action. Do you know if there are early implementations, even if this spec is not set in stone yet, is anyone playing with these already?

Tim Cappalli: In August, we announced that we were going into private preview. We also called it continuous access evaluation without the P. So it's a little bit confusing, but that's a Microsoft's implementation of the draft of CAEP. And really, if you're familiar with Microsoft services, there's about a hundred things that are part of Microsoft 365, all which could be kind of treated as independent applications in many ways. So we really needed an internal way to do this big session revocation use case, right? Like how does SharePoint online know that this session was revoked for X, Y, and Z reason? And so that was a really good test case for us to really vet the idea of CAEP and bring feedback back to the working group. So we went through, we started implementing that about a year ago with the understanding kind of between the standards team and the engineering team that they would have to be on a track to implement the final spec. You know, it couldn't be proprietary. So that led to internal usage of CAEP very heavily, really big during COVID at Microsoft scale. The number of tokens that are minted per day are in the billions and being able to extend those tokens to 24 hours instead of one hour, but still have the security guarantee of a session revocation was huge, especially during COVID times with the exponential increase in usage. So that was huge. We have just started talking to external parties as the spec matures a little bit, and we're starting to get feedback as Atul just mentioned. We're really starting to have those external conversations to ensure that common use cases for integrating with other large multi- tenant type companies can be met. And really we ended up real quick, just a summary of the event types that we ended up with in CAEP that will be in the public draft are session revoked token claims change, which an example of that would be location. We went down a path of having very, very specific events like location change. And then we realized we could just make it a little bit more generic so that you can convey any attribute that was in a token has changed, right? That makes it much more flexible and much more easy to implement credential change, right? I either changed the password, revoked a FIDO authenticator, very flexible, again, revoked an X509 certificate and assurance level change, right? So in one session I used a strong authenticator and in another session I used a password right there, maybe there was a use case where multiple services wanted to know about that. And then the device compliance change, which is your kind of your traditional mobile device management kind of boring one, those use cases covered. We essentially had a use case document and those covered actually a significant number. I think we still have some work to do there, but, and it allowed us to start work and start talking to external parties and another member company who, I don't think they're ready to announce anything. They actually have been working on some style of SDK. They're not sure when, or if they're going to be able to open source it, but there's a very well- known name. So there's a lot of excitement there that they are working on it. And I think Atul you had mentioned, you guys are obviously actively looking in.

Atul Tulshibagwale: Yeah. So in Google, we're not using CAEP internally because our internal system works differently, but we're definitely working on an implementation to inter- operate with external parties to CAEP, to bring the same kind of instantaneous updates that we have within Google to external parties.

Vittorio Bertocci: Fantastic. This is really good. It's great to know that this thing is not just on a whiteboard, but there are actual bits being flung around. That's fantastic. We already got the call to action for people which is to give feedback and participate in this phase now that we are close to crystallizing. So I think that we got a great overview. I'm confident that the listeners now, if they never heard about the working group or CAEP. They now understand it way more about how it works. That is clearly really important work. So thank you for doing that and thank you for participating. We'll keep digging. And so as the spec mature, perhaps we can have another episode in which maybe we talk about the actual deployments and implementations, once they will happen. Otherwise, thanks Tim and Atul for your time.

Tim Cappalli: Thank you for having us.

Atul Tulshibagwale: Thanks for having us.

Vittorio Bertocci: And thanks everyone for tuning in, until next time. The OpenID Foundation is a proud sponsor of the Identity, Unlocked the podcast. Since its formation in 2007, the foundation has committed to promoting, protecting, and advancing the open IT 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 everybody for listening. Subscribe to our podcast on your favorite app or at identity unlocked. 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. Copyright 2020, Auth0 incorporated all rights reserved.