So thanks everyone for attending and thanks to you for having me here as a speaker. So glad to speak about Cape and Shared Signals. It's been a big part of my work for the last, I guess, four years. And my current company Signal is just a year and a half old. So before this, I was at Google and that's where some of this work got initiated. And so let's jump right into it and well, let's talk about the problem that we are trying to solve, right? So the basic issue is that in a zero trust environment where, you know, you don't have a firewall or you don't have some network infrastructure, that once you cross that you believe everything is secure, which by the way has been proven to be a sort of a misplaced belief. But what you want is for every access that you make, that you want to make an independent decision about the security of that particular access, right?
And as a result, you need independent services to be able to determine whether a user that is coming to them, yeah. Are, is that user session trustworthy, right? Is that user session still alive, right? Has the user logged out of somewhere else? Has there been some change to that user's properties somewhere else? And as a result, would, you would place less trust in that session than before? There is no sort of way to do that today, and that is what we are calling, I'm calling as the, the zero trust security problem, right? So you can log in users using federated identity to wherever they want to be. Now you have these hundreds of sessions that are going on, especially if you're on a mobile device, it's gonna be for days or weeks. And how can you make sure that if there is some change to those session properties, to the user properties, that that can be conveyed to where it is needed, right?
And so let's take a look at the past a little bit as to, you know, how this got created, right? So even before Zero Trust became a thing, right? When ever since we had federated identity, people have been talking about continuous authentication, right? So this is where the user will somehow be able to authenticate themselves every time they access this service. But we really didn't have a solution for this. There was a lot of articles written about how hard that this is. You know, there's, you know, it doesn't seem to be a good way to do this and all that. And the other other thing we need to sort of think about is that it's not just about the identity provider and the service provider anymore, right? So you may have an independent device management service, right? Which is providing, you know, updates of the OS to your device, or which is providing the right applications to your device and things like that.
The management settings and all those things, right? There may be an end endpoint security provider where it is like an antivirus or it's trying to look for things that malware that is infecting the device and all that, right? So there may be credentials scanning services that are scanning the dark web to see if the password that you are using is actually out there and, and can be accessed by attackers, right? So all of these are, you can say independent sources of truth, and so it's no longer sort of just a single source of truth kind of environment, right? So you can get reliable information about different things that affect user sessions from different places. And as a result, what do you want is something that will work in this whole environment, right? And so how do we solve this problem? And that was sort of the, the realization that that we came to.
And this was when I was at Google, I wrote a blog that sort of talked about how this can be solved using an asynchronous publish and subscribe methodology, right? So what that means is anybody who has information is free to publish it to the user, to the, to the network peer, the the party on the network that is interested in that information. And there should be some negotiation about, you know, let's say I am talking to a particular service provider. The service provider says, Hey, I'm interested in all this information about the user, but the identity provider says, well, I can only give you this information about the user, right? So there should be some negotiation about how you set up that communication channel, right? So what, so the publisher should be free to decide what they're willing to share, and the, the receiver should be willing, should be able to specify what they're, they want to receive from the publisher, right?
And so this out, this idea was outlined in, in February, 2019, you know, seems like a lifetime back now. And then what happened was this sort of created a very organic kind of interest from a lot of companies. And you know, we had the first meeting in Google, which was attended by 30 plus companies, people flying all over the world. It was really amazing to see these companies get so interested in this so quickly, right? So clearly everybody had the problem, everybody was looking for something, and this was just one thing that sort of led to the, to the growth, right? And in the meantime, what was happening was, in the Open ID Foundation, there was another group called Risk and Risk here stands for Risk Information Sharing and Coordination. So the idea there was basically that you could, you could potentially, there could be an attack which involves users, attackers trying to compromise the same users account on different providers like Google and Facebook for example, right?
So this is sort of the coordinated account compromise kind of attack. And there was no way for these providers to convey to the other provider that, hey, you know, this information needs to be shared so that they can be alert that this there is an ongoing attack on this particular account, right? And so that was the risk idea. And the, the great thing about risk was it also worked on a asynchronous publish and subscribe kind of mechanism, all right? And so what we thought was it would be a good idea to sort of unify these two efforts. Firstly because the mechanisms, the underlying mechanisms had a lot of similarities. And the second reason is because in, if you think about implementations, those people who are interested in account security will also be interested in session security. And so it'll be hard for them to, it'll be unnecessarily hard for them to implement two different stacks, which finally come down to the same set of services that have to handle security for accounts and security, right?
And sessions. And so we, we merged all that into CR into what is now known as the Shared Signals working group For a while, this was called the Shared Signals and Events Working Group sse. Now that name has changed to Shared Signals Working Group and the output of this working group, the main output is called the Shared Signals Framework. And I'll explain to you what that, what that is. But Cape and Risk are now two profiles or two applications on top of the Shared Signals framework. And so this is what, this is what the sort of the standard stack now looks like, right? So there is the underlying layer, which is a shared signals framework, which provides you the asynchronous publish and subscribe mechanism. What is going on? These streams of events that, that go between the publisher and the subscriber are security event tokens.
Now, security event tokens are basically just jots and then go into what, what they are in a little bit. And they can specify for each event who is the subject of that event. And that subject of the event can be specified as finally as you want, or it can be specified as broadly as you want. So you can say this event applies to an entire tenant, right? Could be, you know, thousands, hundreds, or thousands of identities, right? Or an event could be specific to a particular session on a particular device belonging into a particular user. So it can be that fine grain or it can be very broad, broad based as well. It, it has some sort of stream management capabilities that let you start, stop, pause the stream, verify that the stream actually exists, so you know that there is liveness in the stream.
And then also reliable mechanisms of sending information, basically using push or pull mechanisms, right? And so all that is covered in the, in the shared signals framework. Now, the continuous access evaluation protocol, which is now called the Continuous Access Evaluation profile of Shared Signals and Sales Signals Framework, uses that framework to convey events that relate to session security. And I'll get into that into a little bit. And then the risk protocol is now another profile of the Shared Signals framework, which deals with account security events. So these are like account purged, account deleted, you know, account activated.
There's one thing which is like credential change required. So the, the account provider has determined that the user needs to change their credential, but you know, you don't know if the credential has been changed or not. Credential compromise and stuff like that, right? So we can, I'm not gonna go into the details of risk here. I want to talk more about Cape because of the sort of the zero trust interest. And so let's, let's get into that a little bit before we go there. Let's, let's talk a little bit about the reliability, right? The delivery in Cape or in Shared Signals is reliable. What that means is that when you send an event, you know that the receiver has acknowledged that event to you, you know that the receiver is in possession of the information that you have sent them. Right? Now, these protocols, like Cape specifically, is not a prescriptive protocol.
So it doesn't say, say an event that you need to do this to the receiver, right? It just describes an event like the user's password has changed, right? That's an event. What the receiver has to do with it, it's its own business, right? But what the protocol allows for is for the receiver to acknowledge that it received that event, whether it processed that event or not, is outside the scope of this protocol, right? And so what you get is basically if you're pushing the event, you get a 200 status, which means that the re the event was received, if you're polling, you actually have to acknowledge the, the Java, you know, j w t identifiers called JTI back to the transmitter so that you know that that particular event was actually received by the receiver. Right? Now let's take a quick look at the events supported in Cape.
And the first one, which is of the most interest to people is session revoked, right? Which is you have a user that has used an identity provider and logged into let's say hundreds of services. Now the identity provider has for whatever reason revoked that user's session. It's able to send that event now to anybody who's interested and to whom that identity provider is willing to send that information that I have revoked the session on my end, right? What the receiver decides to do with that information is not specified by the protocol, right? So it just says that, you know, I've, and chances are the receivers gonna say, okay, if the identity provider doesn't trust this user anymore, I'm gonna like request a re authentication or something like that. You can send a token claims change event, right? So for example, in a SAML token or in an Open ID Connect token, you can include information about the something related to that session.
For example, you know, just just as an example, the aws, you know, Amazon Web Services infrastructure. When you send a user using Federated identity to that, you can specify the resource identifiers that that user may have access to in that session. Now, if for some reason the, the identity provider wants to say, you know, I don't want this user to access this particular resource identifier anymore, you can use Cape to send a new message that says, now this user has access to these resource identifiers. Again, what the receiver does with that information is up to the receiver, but that the mechanism is provided in the protocol, you can convey a credential change. And that could be an identity provider, it could be your directory, or it could be something else. An assurance level change. Let's say the user has signed in using Password now has done a two fa you don't want every application to prompt the user for two fa that can be conveyed using.
And then device compliance change is something that maybe a device management service consent, which is they've, they have the device under management, but the device management service requires the device to check in every few hours and the device has failed to, to check in. So now the device is no longer compliant, the device management service can send out that, that event, right? So these events are all supported in Cape and this, the effect is that if you process these events in, in the way that is appropriate, it can bring a lot of security to your existing sessions. So, you know, before we jump into Cape Do Dev, I'd just like to take a moment to see if there are any questions so far about Cape.
Alright, we can, we, we can save the questions for the end. Let's, let's jump into what is cape.dev? So one of the challenges is getting adoption for the standard. Now the standard has been in development in, in the Open ID foundation since I, I guess coming upon about two years. And while there are implementations like Google has their own implementation of the risk standard, which is based on Shared Signals framework, they send out, you know, millions of events every day to, you know, hundreds of thousands of applications. Basically, if you get a Firebase SDK based application, it's automatically ha gonna have risk in there, right? On the flip side, on Cape, Microsoft internally uses Cape Events between their services and they send millions of events within their services. But public facing implementations that interoperate between parties with Cape is not yet there. And while there is a lot of interest have spoken to, you know, tens of companies that are all interested in supporting, but you know, we, we just need feel that there needs to be some kickstart to this.
And so we have come up with this thing called cape.dev. Now my company Signal that you can see in the corner there. And if you're curious about what Signal is you, you can go to the top floor and we have a booth there and you can, we can, I can tell you how all about it, but this is a non-commercial thing. There's no sort of commercial interest in building this. The cape.dev basically is a free transmitter. So if you're developing your own receiver, you can use cape.dev to generate events that you want to be sent to you, right? And I'll show you a demo of how that works. And it's, it is, you know what, one of the criticisms we've heard sometimes is, oh, Cape is too difficult to implement like shared signals. And I'll show you that that is not true. It's extremely simple. We have a little Postman collection with just two methods and that's a Cape Receiver, right? And we have a Cape Transmitter that is like a very simple thing. So Cape Shared Signal is extremely easy to, to implement, right?
So this is what, what has been happening in the industry. I told you about the Microsoft feature called continuous access evaluation. There's the Google Risk Service. Cisco and Box have made announcements and I properly demonstrations, and then my company has launched Cape Dev. That's sort of the story so far. I know this is gonna change next year if we have a session on Cape, I'm, I'm pretty sure there's, there'll be a lot more to talk over here, right? So let me switch gears and, and jump into a Cape demo here, right? So this is, this is cape.dev and before we jump into the demo, let me show you that it has a learning section that has like an instant recipe that shows like, you know, how you can, you know, build a transmitter, a receiver and just get started. And we are gonna do that today.
We are gonna build an actual receiver and, and get an event sent to us. It has an faq, it has, you know, the, some presentation that introduces the spec and, you know, talks about the various events that that Cape has. Right now, let's, let's get started. Let's register ourselves and I'm gonna register myself here as a registrant and I'm not a robot, so I'm gonna do that and it's gonna registration, you know, it's gonna register me. Now I'm gonna look for that email, that email that I got and here's the email and I'm gonna click the link that lets me complete my registration. So, you know, my organization is Signal, it's a small company and I'm like immediately developing and there's a receiver, you url, you can enter anything here. This is basically in, in Cape. You need a unique identifier for every receiver. This is my unique identifier. So I'm just gonna put something there and I complete the registration. And now what it does, it, it lets me access access, you know, get the access token. So I'm gonna download the access token and here is the access token that I got, right? So I'm gonna, one minute. Oh my God, okay, yeah. So let me jump right there. You know, I'm gonna go to the re the transmission part and I don't have a receiver, so I'm gonna download the, you know, the Postman collection for the receiver. Here we go.
Here's the Postman Collection. I, I open the post, actually, you know what I'll do? I'll go to Postman and I'm gonna import that Postman collection right here. And let's start a stream with the receiver, create a stream. I'm gonna put the authorization header, which is that access token that I just got. And I'm gonna send, so now a stream has been created with the transmitter. Just this will take a second. So now I'm gonna pull for an event. And so what I'll do is before I pull for an event, I'll generate an event here, okay? So for, okay, so nevermind. So because I'm running out of time, I'm I'll, I'll show you the demo, come to the booth, I'll show you the demo there. Right? Let me just say that we are, we are seeing strong interest and you know, all, all you need to know is it's extremely simple. You can start, get started today and you know, you'll find it to be a much a great improvement in security. So, you know, ask me any questions up there at the booth or, you know, after this session I'll be outside. Thank
You. Well, thank you very much at all. It was really great and, and it, it does raise a lot of questions and actually have a list here on my tablet, but while we have to reserve them for you both, so anyone interested come around Yeah. If it signals, thank you very much at all. Thank you.
