Extending the Horizon: Enabling Real-time Identity with Event-Based SCIM [Advanced]

I want to start off this morning, afternoon, with a controversial statement. Dolphins are jerks.

Oh, well, it's odd to say it, apparently. A little bit odd, right? Because most people like dolphins. It's come to my attention recently. A couple of my friends pointed out that dolphins can be, in fact, not nice. A friend of mine, his name is Jeremy. I won't tell you, and now we're just going to keep on going. I'll tell you his last name. He told me once that dolphins will steal your fish, and they will steal your girl.

He told me about a time when he was kayaking in the coast of Texas, and he had been fishing with his wife, and dolphins came, and they actually ate the fish from beneath his kayak. They also surfaced right beside them, and blew, like, shot air and water. He thinks just to startle them.

Now, it's debatable whether or not they actually came and took— it's going to get there eventually— came actually back for her, and she left with them, right? But the graphic was too attractive to pass up. So dolphins are jerks because I would say they're kind of selfish, right? They want the fish. They want the girl. Stop going ahead. All right. Ultimately, because they're selfish, right? And a lot of vendors in our identity and security space are like that. They get data. They get information.

They have context about identity, about their attributes, and what they can do, what they can't do, and they don't want to share it. But dolphins are also awesome, right? There is a scientific paper—ooh, hands-free. You can see the link at the bottom here that actually researched about at least 16 species of dolphins in the world that cooperatively fish with humans. And more specifically, I want to talk about this one right down here in Brazil. And by the way, you should definitely read the academic paper. It's going to get there eventually, I promise.

The way this works is really, really simple, right? You have dolphins. You have fish. You have fishers, right, standing on the shore. They don't look like they've got—they just come from the office. They actually have nets. And the dolphins actually herd the fish in towards the fishermen, and at some point, they actually give the fishers a signal, right?

They say, look, I got fish for you. It might be a good time to throw your net. The fishers throw their nets. They catch more fish. The dolphins swoop in and actually get some fish for themselves. It's a model of cooperation. It's great. It looks and sounds kind of like this. Dramatic reveal. Once it advances in the water. They get mad when they start to eat. You should have two thoughts in your head right now.

One, that's the kind of academic research I want to be involved in. And two, Mike, you just wanted to play a video about dolphins, and you're right on both counts. But what this does is it proves that dolphins can be awesome also when they're cooperative, not when they're jerks. And really, it's great, right? Because this relationship is mutually beneficial, right? The fishers catch more fish. The dolphins get a couple of fish by cooperating. And as long as the fishers are fishing with these nets, dolphins survive longer.

They have a 30% more chance of surviving because the fishers aren't fishing with nets. They're fishing with fishing boats that cast huge nets and actually kill dolphins. And so this motivation, this cooperation, of course, is one of the ideas behind SCIM and a new standard that is in last call in ITF that does SCIM on an event-based basis.

Now, you should also be thinking to yourself, Mike, this sounds a lot like shared signals framework that you mentioned on Tuesday, Monday, whenever it was before. And I'd say, yeah, you're right, right? If you think about shared signals framework, there's this transport layer that does a pub-sub, event-based stream of real-time identity context and data between disparate sources, right? And on top of that transport framework, keep in mind when someone says shared signals framework, they're just talking about this transport layer. They're talking about the plumbing.

They're not actually talking about the event types, right? They come in on top of that transport layer, right? And so you have right-to-left, you're right-to-left. You have risk events, which are account-level events. Then you have CAPE, which you may have seen at Interops and is kind of the new hotness, session revoke, token claims change, device compliance change, those kinds of things. But then eventually, you also have SCIM events coming.

And it's a little bit different, right, because these other events are a little bit more, hey, you might want to do something, and SCIM is more sharing event information directly, but they all use the same kind of plumbing, right? Now, it's important to note at this point that SCIM doesn't actually have to use... Getting there, hold on.

So, by the way, here's the URL if you're interested in reading through the spec. I can put a QR code on LinkedIn or something, because I know it's really hard to type all that. It's important to note that SCIM events doesn't require shared signals, the framework, right? The way it was written, we said, look, this is a standard. It doesn't necessarily need a shared signals framework, but it can use shared signals framework. If you have Kafka, you have Kinesis, you have something else that can do that event transport layer, knock yourself out.

Now, again, it's just SCIM. So in that sense, you have all the normal things you would expect with SCIM.

Create, patch, put, delete. Hopefully, you're familiar with SCIM.

If not, you probably want to go back and read up a little bit on that. You also have activate and deactivate, and that signifies whether an account is ready or not for usage, but you want to have those conversations between the transmitter and the receiver or the service provider and the client beforehand and make sure you clearly communicate what that significance is semantically. Looking at an event, we'll just go real quickly through an event. And nothing really is too shocking here, right? This is just a security event token.

There's a transaction attribute so you can keep track of what's been sent, what's not been sent. You'll have the subject ID, which is a format of SCIM with the URI like you would see in a normal SCIM transaction, potentially an external ID if it exists. And then you have what the actual SCIM event type is. Is it a patch? Is it a put? Is it a create? Along with a version number. And then the next stanza, it's one of two things. It's either a data stanza with all the data right there for you to use, or it's a list of attributes that have changed that you might be interested in.

And that semantic difference, the difference between those two things are the difference between full and notice. If you look at an event type, the end of it is full or the end of it is notice. Full means you get everything. Notice means you just get notification about this is what's changed. You might want to come ask about this. What that means is that if it's a full event, it's kind of more of a domain-based replication kind of use case. And this is specified in the standard.

This is where you have an operation done on a SCIM provider, and you want that change immediately on the replica or on the hoolers on the other end of that. Everything's in that event, so it can be processed and updated and keep them together. Notice is a little bit different, right?

You get those attributes, and then what happens here is instead of just duping directly, they get the SCIM event, and then the co-op receiver can decide what attributes they're interested in, and on a back channel can go and get those attributes as desired, which is pretty great from a, hey, I don't want everything you have necessarily. I just want what I want to know about or I want to update now. So let's real quick run through the technical bits, right? You can read the spec. You can come ask us questions, all that kind of stuff.

I want to talk about the so what, because standards are great, but what benefit could this possibly have? So a couple of thoughts around that, and we can talk about these afterwards if you're interested. First off is the idea of real-time provisioning or to use a marketing phrase, zero standing privilege, right? What do I mean?

Well, traditionally SCIM takes a while, right? It's batch processing. If it's event streaming, now the game has changed, right? Technically, I could keep downstream clients up to date with the latest identity attributes and group memberships and all of that in near real-time. But the fact of the matter is, despite what marketing may or may not tell you from a vendor, you're probably not going to do zero standing privilege across your whole organization, right?

For the foreseeable future, my argument is that it's going to be kind of a federalism in the Swiss mode model where parts of it, you may flip to real-time. Sensitive, detailed parts of applications or whatever and applications, you may turn those to real-time, but it's not like you're going to flip the entire organization to event-based real-time streaming because the cost and speed and scale, frankly, just isn't worth it. That's what this pretty picture was supposed to represent. Second off, this goes hand-in-hand with the other Shared Signals framework event types, right?

CAPE and RISC works hand-in-hand with SCIM events. Co-chair of the Shared Signals framework, Atul just put out a blog on the OpenID website talking about some of this interaction, not with SCIM events, but CAPE and AuthSend, but the similar experience here, right? If you have a CAPE event, that can trigger or result in a SCIM event, which makes some kind of sense.

If you have a device compliance change event saying, Kaiser's device is no longer compliant, well, then maybe on reception of that, I'm going to go issue SCIM events to go change access, remove access from anything sensitive that by my own policy requires his device to be compliant. The same thing the other direction, right? You can have modification come in through SCIM events that result in a CAPE event.

In this case, maybe my entitlements change or my attributes change, which results in an access change, and I want to issue a CAPE event saying, if you have a token for this person, you probably want to go and reevaluate the tokens inside that claim, right? Next up, let's think about real-time authorization data. My friends in AuthSend have already presented a couple times this week. I think that SCIM events has the potential to go hand-in-hand with default authorization models. And in fact, normal default display here, right?

My question is, this policy information point down here, how old is that data, right? Your policy decision point is only going to make as current of a decision as that data is of the moment. SCIM events, I think, in the long-term future can be used to update those, keep those up-to-date, so that when the PDPs engage, no matter where they are, if they call out to a PIP or a data store, they can make the right choices.

Next, privacy and data minimization. Aspects of this are actually in production in a few organizations that I know about today. Believe it or not, even before the standard has been through complete last call. Privacy and data minimization, this goes back to that notice vibe, right? If you're not getting all the information, now you can just say, well, I don't want everything. I just want the ones I care about. Maybe username or external ID. I probably don't want your whole genome sequence or your favorite child. Then again, maybe you do. I don't know what app you're actually writing.

But at the same time, what this is, is the less data we have everywhere, obviously it enhances privacy use cases. And then finally, as should be kind of obvious, right? This can stream into an audit and compliance record for everything that's gone on within the environment so that you have a record of what's been done, what's changed, and why over time.

Finally, just a couple of open source repositories written by one of the co-chairs. I'll have one out later this summer. Originally, I had thought about doing a live demo, but then I decided that skim events as a demo is probably the most boring thing I can think of in the world. So if you have ideas for how to do that, let me know.

In short, I was going to try and leave that slide up, but we'll go back to it. Basically, my advice to you is that we should be like dolphins, obviously, but not like the jerk dolphins, like the awesome dolphins. And while skim events is still really new, there are a couple of people who are implementing it already. If you're interested, come and find me. I think this is kind of the next logical step in the progression of skim events and some of this move to real time for a lot of organizations. Thank you. Thank you very much on this final talk and this trip before we have the lunch.

Any questions from your side in terms of this talk? Not so far. Then maybe one from my side.

As I said, I have always questions. Now, as you said, it's pretty new. Do you foresee that it is really like fixing something at the moment that a lot of your customers out there are fixing so you expect a quick adoption of it? So what would you see for the enterprises? Is it really something they are aiming for, needing, or is it just something where they say, okay, we saw the benefits, it's there, but as you know, resources are limited?

Yeah, two thoughts. One, I think that no one says, I want to grant access and let it sit around forever. So the more that they can move to decisions in the moment, whether it's using fine-grained authorizations or authorization policy or something like skim events to update resources and basically kind of grant access and then take it away in the moment, I think people will move towards that. I think that's one of the advantages of sitting potentially on top of something like a shared signals framework. I've seen a fairly strong adoption of that.

And so if you already have that, building in skim events on top of that, I have hopes that that makes an improved production path. So like I said, still early days. But this is actually the first time that anyone's really publicly talked about skim events as far as I know. Quick question.

Mike, does the spec cover the message format or covers also the transport? Because you mentioned Kafka and others.

Yeah, it does normal. There is a security consideration section advising on what you should take care of. It does not specify how you transmit the events. It basically just says, hey, there's a push approach and the pull approach from, I can't remember the RFC numbers, but the RFC is saying that's probably the direction you want to go. It should support that. And so shared signals fits that, but it's no. We tried to make it as less prescriptive as possible so that people could do it in the way they wanted to.

Right, message format rather than the transport layer. And it's a profile also, right?

Okay, one last question. Yeah, quick final one. What's the main difference between having this event format or what can I do with the event format that I can't do, for example, with standard patch operation? The patch operation itself is very similar. But patch exists both in the skim 2.0 and skim events, right? The difference is when that's going across, right? Some people can implement that very quickly, but it depends on the system, right? Some organizations batch up all of those events and then, events, excuse me, those skim commands and then put them in an endpoint kind of a scenario.

So I think here, to me, it's a move to real-time action and reaction rather than a different patch. You have time for one more question?

Yeah, so now it starts. The commercial products are ready to support skim events? Which ones? Sorry? Commercial. Any of them?

Yeah, any of them. Where are you in the stage of adoption?

Yeah, that's a great question. I think still really early is my immediate reception, right? So I think there are a couple of... There's obviously the open source implementations that I displayed there. There are one or two people putting it in production, but they are independent organizations with political will and technical know-how to do that, right? I think real adoption is with the vendors providing that as a default, right? I think that's a longer runway. I think there may be one or two in the next six months to a year.

But again, standard adoption is always a game of incentives, right? And it depends on what the need is. I think it goes hand-in-hand with some of the other work that's being done, like in the ipsy working group and some other things, where you default have... Right now when you single sign-on, you get that JIT. You can have JIT provisioning. This is a very similar mechanism, except you might have the whole lifecycle accounted for instead of with JIT provisioning and single sign-on, you get the account created, but then it potentially is abandoned, if that makes sense.

So I think there are advantages here. But again, I can't speak for what vendors' plans are, right? I have hopes. That's what I'm trying to do. So we hope a lot of vendors have heard it and are still already working on it.

So then, thank you very much. Then we are closing this track.