WEBVTT 00:00.000 --> 00:10.000 Yeah, thanks everyone and good morning. 00:10.000 --> 00:17.000 My name is Thomas and I'd like to give you a brief introduction to the shared signals framework as introduced. 00:17.000 --> 00:21.000 First of all, me, the self-employed identity consultant, 00:21.000 --> 00:24.000 I love digital identity and standards. 00:25.000 --> 00:31.000 I'm involved with some open-source projects and I'm also one of the maintainers of the Kiko project. 00:31.000 --> 00:37.000 And I also work at the Open Adi Foundation in the certification team where I develop 00:37.000 --> 00:41.000 conformal testing software for internet identity protocols. 00:41.000 --> 00:50.000 Like, open the Connect Fabi2, Open Adi for verifiable credential issuance and, of course, Shedsignance framework. 00:51.000 --> 00:55.000 Speaking of which, maybe brief description about it. 00:55.000 --> 00:58.000 What is the shared signals framework in a nutshell? 00:58.000 --> 01:04.000 The shared signals framework is a protocol that provides a standardised way for identity systems 01:04.000 --> 01:10.000 to communicate events in a trusted way between parties to improve security and user experience. 01:10.000 --> 01:17.000 It's governed by the Open Adi Foundation and we are the shared signals framework working group. 01:17.000 --> 01:22.000 It's an open working group. You are all free to join if you're interested in that topic. 01:22.000 --> 01:29.000 And its main goals are to enable real-time communication of critical security events 01:29.000 --> 01:35.000 and to reduce complexity by standardising event formats and delivery mechanisms 01:35.000 --> 01:40.000 to enhance interoperability across identity systems. 01:41.000 --> 01:49.000 Giving you a small example. If you think of a scenario where you have a thus application and some connected identity provider, 01:49.000 --> 01:56.000 you can imagine that when users use the system, there might be different things occurring 01:56.000 --> 02:00.000 that the particular application or system can observe. 02:00.000 --> 02:09.000 Use the abnormal user behavior, maybe some threat detection kicks in, or some user posture, 02:09.000 --> 02:14.000 how it is using the system indicates some abuse. 02:14.000 --> 02:26.000 Also, identity providers that might be used with us systems might produce their own sort of a set of signals to indicate problems, 02:26.000 --> 02:30.000 like different devices suddenly being used. 02:30.000 --> 02:34.000 The user performed an impossible travel or something like that. 02:34.000 --> 02:43.000 Or we detect a user risk-scoring detected some issues or IP enrichment or IP reputation data 02:43.000 --> 02:48.000 was taken into account and we detected that the user came from a suddenly comes from an IP that has 02:49.000 --> 02:52.000 known buttoned buttoned behaviors. 02:52.000 --> 02:58.000 All those different signals comes in different forms of shapes depending on the product that emittered up. 02:58.000 --> 03:08.000 And shared signals now tries to uniform and normalise those events such that you can enable continuous access evaluation, 03:08.000 --> 03:17.000 really detect, unauthorised access, credential theft, data, exploitation, or letter-remoofment or even privileged escalations. 03:17.000 --> 03:23.000 And let's see how that works. 03:23.000 --> 03:26.000 Give you some additional use case examples here. 03:26.000 --> 03:31.000 For one use case could be that you want to perform real-time session replication. 03:31.000 --> 03:37.000 So if an identity provider detects that some account got compromised or has some other issues, 03:37.000 --> 03:41.000 they can signal all the relying parties about it. 03:41.000 --> 03:46.000 And maybe they can then revoke the sessions of the current user. 03:46.000 --> 03:52.000 Or we can detect that an account is compromised and we can then trigger the development of sensitive applications. 03:52.000 --> 03:53.000 Accounts let's say. 03:53.000 --> 04:01.000 Or we can help with automatic user deep provisioning that upon termination of a user account, 04:01.000 --> 04:09.000 we can help systems prevent off-and-accounts that keeps the active even though the user is already deactivated. 04:09.000 --> 04:12.000 And other systems. 04:13.000 --> 04:16.000 What are the building blocks of shared signals framework? 04:16.000 --> 04:20.000 Let's see, of course, first of all we have to secure it event. 04:20.000 --> 04:29.000 This is basically an event resulting from some observed behavior of a user, a system, or a device, or a combination of it. 04:29.000 --> 04:32.000 Then we have a thing called the transmitter. 04:32.000 --> 04:35.000 The transmitter is a system embedding a security event. 04:35.000 --> 04:40.000 For instance, could be an identity provider. 04:40.000 --> 04:47.000 Then the events, security events, it middard, are then received by a component called the receiver. 04:47.000 --> 04:51.000 The receiver is a system consuming the security event. 04:51.000 --> 04:56.000 For example, a source provider or any relying party is included. 04:56.000 --> 05:03.000 And of course those events are managed in a logical subscription that we call stream. 05:04.000 --> 05:13.000 And this is basically grouping certain security events that are received as interested in, which are managed by the transmitter. 05:13.000 --> 05:21.000 So, to illustrate that in the graphic, imagine we have a shared signal framework transmitter. 05:21.000 --> 05:24.000 And we have a shared signal streaming receiver. 05:24.000 --> 05:32.000 And the receiver basically creates a stream on the transmitter, like a subscription, which tells the transmitter. 05:32.000 --> 05:36.000 By the way, this receiver is interested in this sort of security related events. 05:36.000 --> 05:45.000 And then, once the transmitter emits those events, there are many different ways this events can be transported. 05:45.000 --> 05:50.000 One of those methods is an async transport, so to speak. 05:50.000 --> 05:58.000 And the event that is transferred is a so-called security event token, which is basically a signed JSON web token that has a special structure. 05:58.000 --> 06:10.000 And that contains information about the subject and the event, let's say, that was the cause of that particular security event. 06:10.000 --> 06:21.000 The shared signal streaming protocol stack uses a set of well-established standards, like for instance, the JSON object signing and encryption. 06:22.000 --> 06:26.000 So, that's for JSON web token, JSON web signature and so on. 06:26.000 --> 06:33.000 Building up on that, we have the security event token, which is the signed dot that carries on the event information. 06:33.000 --> 06:48.000 Then we have to push to delivery methods, push and pull methods, and standard to identify identities, so to speak. 06:48.000 --> 06:52.000 And on those pillars, we have then the shared signals framework. 06:52.000 --> 07:03.000 Shared signals, very basically combines all those underlying protocols and prescribes how to set up a set from a transmitter and receiver. 07:03.000 --> 07:11.000 What metadata is provided and what inputs and points it to be provided in order to interact. 07:11.000 --> 07:18.000 And we have some profiles on top of that, with Cape and Risk, we'll explain later what it is. 07:18.000 --> 07:26.000 Those describing basically a set of use cases and events that are carried over this shared signals mechanism. 07:26.000 --> 07:29.000 Let's see, in more detail. 07:29.000 --> 07:37.000 First, the security event token, or abbreviated as a set, so to speak, this is IRC 8417. 07:37.000 --> 07:42.000 It's a set of JSON web token based format for conveying security related events. 07:42.000 --> 07:52.000 It includes a standardized event type with an event specific payload, with a subject identifier, and some metadata. 07:52.000 --> 08:03.000 The security event token is basically signed by the transmitter for non-reputation in the security protection, and of course verified by the receiver. 08:03.000 --> 08:14.000 The subject identifier is using this IRC 9493, and that's a standardized way to reference identities across systems. 08:14.000 --> 08:24.000 You can imagine that an identity can come in many forms and shapes and sizes, let's say, could be a person, a device, a group, an organization, a tenant, or even just a session. 08:24.000 --> 08:34.000 And you can imagine some systems refer to identities we are email, other have their own identifiers, other use some other means, like a username and so on. 08:34.000 --> 08:52.000 And the subject identifier standard gives you a way to basically describe in which format you want to reference an identity, and you can also use multiple forms of reference to refer to the same identity, such that it is interoperable across systems. 08:53.000 --> 09:06.000 This is an example of a security event token, as you can see it's a job, and in the header we have the special set token type which is sec event plus job. 09:06.000 --> 09:15.000 And in the payload we have of course the issue of this particular event which is the transmitter, of course. 09:15.000 --> 09:27.000 We have the audience to which this event is intended, and we have some other information like the subject, in this case we see we want to refer to an identity via email. 09:28.000 --> 09:40.000 And then we have the event specific metadata, like the event type, as a UB, and some event specific payload that comes with the actual event. 09:40.000 --> 09:47.000 And of course it is signed with some kind of JSON website signature. 09:48.000 --> 09:51.000 That's it. 09:51.000 --> 09:57.000 For describing those events, there are two profiles as set. 09:57.000 --> 10:07.000 One is basically cape, cape is abbreviation for continuous access evaluation profile, and was initially defined by Google. 10:07.000 --> 10:15.000 And this is basically as a profile that enables continuous monitoring and evaluation of access decisions based on sessions. 10:15.000 --> 10:26.000 So an example events that this profile brings are for instance session revoked, token clips changed or risk level changed. 10:26.000 --> 10:36.000 Next to that we have a risk profile which is sending for risk and incident sharing and coordination. 10:36.000 --> 10:47.000 This profile is basically more focused on disaster mitigation and related to security risk and incidence of user accounts of real accounts. 10:47.000 --> 10:55.000 And example events are credentialed compromise, credentialed change required or account is able to answer on. 10:55.000 --> 10:59.000 And first there are some other profiles as you will see in a bit. 10:59.000 --> 11:03.000 And yeah, but this are the most commonly used ones. 11:03.000 --> 11:09.000 And just give you some more examples what kind of events you can express with this profiles. 11:09.000 --> 11:16.000 A set session revoked of course to have some kind of glorify global lockout capability. 11:16.000 --> 11:20.000 But others also include device compliance changed. 11:20.000 --> 11:33.000 Now when your device compliance routes in your company changed for some reason you can signal that to other interests of parties and they can then act accordingly. 11:33.000 --> 11:48.000 Or on the risk side we have account perched and count disabled account enabled let's say credential compromise or if we have some kind of opt in or opt mechanism we can also signal that an opt out has been requested and so on. 11:49.000 --> 11:53.000 Just to give you a few examples. 11:53.000 --> 11:57.000 Yeah, how can this sets be delivered. 11:57.000 --> 12:05.000 I've said we have two methods. First one is push delivery method which is all the standardized on ROC 89 35. 12:05.000 --> 12:17.000 And this allows receivers to have declare a push end point that they can basically announce two transmitters when they create a logical subscription or stream. 12:17.000 --> 12:27.000 For events and then once the events occurs then the transmitter will send those events to the push end point via an HTTP post request. 12:27.000 --> 12:33.000 And this basically enables you real time event delivery as the event occurs. 12:33.000 --> 12:41.000 There's also the Paul delivery method which is based on ROC 89 36. 12:41.000 --> 12:46.000 And this is basically the transmitter providing a Paul endpoint. 12:46.000 --> 13:02.000 And the receiver now can periodically call the Paul endpoint via an HTTP request with some additional query possibilities which enable a synchronous event delivery and also batching. 13:02.000 --> 13:09.000 That you can receive multiple security events at once. 13:09.000 --> 13:17.000 Yeah, and I said this is just an example how delivery we are push on delivery we are Paul would work. 13:17.000 --> 13:23.000 The transmitter would hold the stream definitions and queue some events for particular stream. 13:23.000 --> 13:32.000 And in the case of push they would basically just call the push end point and acknowledge the received of this event. 13:32.000 --> 13:47.000 And on the other hand we have the Paul mechanism that allows acknowledgement and batching where the receiver periodically carries well on a new events for my stream and so on. 13:47.000 --> 14:01.000 Okay, now you might wonder oh that's all nice who uses this and it's now nice quite a large list already of the companies we're using this just to name a few like Google, Octa, Apple, Jamf, 14:01.000 --> 14:18.000 Saypoint and so on and signal which was previously recently acquired by crowds like all using shared signals and also all the members of the shared signals working group who help develop the standards for their own. 14:18.000 --> 14:27.000 Yeah, just check us remember in the nutshell so to speak is basically an asynchronous puppy subscribe web hook framework with a security delivery mechanism. 14:27.000 --> 14:43.000 It features a stream of security event tokens in Jot format we have the subject identifier structure to refer to identities on multiple levels we have this stream or subscription management capabilities and different delivery mechanisms. 14:43.000 --> 14:52.000 On top we have the continuous access evaluation profile actually for session related events. 14:52.000 --> 15:04.000 Then we have the risk profile for account security related events and we also there's also a standard for skim events that you can. 15:04.000 --> 15:19.000 You can use a provision or entity provisioning events across the systems that's still an idea of draft but some folks actively working on that to make in this reality let's say. 15:19.000 --> 15:31.000 Okay, now so far so good I said I'm also one of the maintainers of the kick-up project and I'm currently working on adding shared signals framework support to kick-up. 15:31.000 --> 15:41.000 And as you can imagine based on what you've heard so far there are multiple ways how kick-up could basically be used in this scenario. 15:41.000 --> 15:48.000 Some of you one of the obvious use cases of course to use kick-up as a shared sequence framework transmitter. 15:48.000 --> 16:02.000 We are based kick-up could basically emit those cave or risk events to interest parties and kick-up could then notify connected identity providers or relying parties about account changes. 16:02.000 --> 16:08.000 Suspension or password credential changes or whatnot. 16:08.000 --> 16:19.000 However there are some challenges here because as you see as you've heard earlier when we want to do support this different developer event delivery mechanisms. 16:19.000 --> 16:28.000 We also need to support some kind of queuing mechanism and so on and this is a bit more involved getting into kick-up. 16:28.000 --> 16:35.000 And of course we need to pulling and pushing for structure to reliably deliver this events. 16:36.000 --> 16:57.000 On the other hand there's also the option of using kick-up as a shared sequence framework receiver which means that kick-up can receive cave risk or scheme events from other transmitters and then kick identity providers could basically propagate account changes session replications and so on. 16:57.000 --> 17:07.000 The challenges here are that kick-up or a shared sequence framework receiver is responsible for managing the stream on the transmitter side so you need to implement that controls and so on. 17:07.000 --> 17:25.000 But at least the event ingestion and queuing as much easier and simpler than adding support for foot transmitter and therefore we decided to first go with a approach of adding shared sequence framework transmit receiver support to kick-up. 17:25.000 --> 17:29.000 And this is what I will demonstrate to you in a second. 17:29.000 --> 17:40.000 First I want to introduce you to CapeDev, Cape.Dev is a free website and implementation of shared sequence framework. 17:40.000 --> 18:06.000 So that with Cape profile enabled that you can use to transmit events to shared sequence framework receiver that you built or if you want to test the transmitter you can let it act as a receiver that you can even send events to and so on to build your own infrastructure based on that and to test some things and that service is what I'm going to use next. 18:06.000 --> 18:15.000 As I said adding this to kick-up is a bit involved because you need some additional infrastructure plumbing to get us all going. 18:15.000 --> 18:33.000 I don't want to explain this into much detail here but the thing that we will see is that kick-up will basically expose a shared sequence framework receiver that you can configure in a kick-up realm which is some kind of a container for. 18:33.000 --> 18:40.000 Yeah identity related structures like clients identity providers and so on and users and so on. 18:40.000 --> 18:55.000 This receiver will provide a shared sequence push endpoint that can be used by a transmitter on this side to propagate and push security event tokens and those tokens are then. 18:55.000 --> 19:11.000 Power is validated and then processed accordingly and this will eventually trigger some kind of a pluggable event listening machine mechanism that you can or users can use to plug in their own logic to react to events that they receive we are. 19:11.000 --> 19:28.000 And yeah to show that in action have a small demo prepared unfortunately right before the talk I had to switch laptops so I cannot show the demo live which I'd love to do but I think for me made a recording yesterday evening so oh we're prepared. 19:28.000 --> 19:40.000 If you want to try that out yourself there's a pull request that contains exact same code that I running here and with that said let's take a brief look at the demo. 19:40.000 --> 19:48.000 And what the demo shows here first we lock in as a user to is it running no. 19:48.000 --> 19:55.000 But we lock in as a user tester to a second page app let's say that secured my kick lock. 19:55.000 --> 19:58.000 I need to click play yeah. 19:58.000 --> 20:11.000 No it's not playing great right second this played right okay okay. 20:11.000 --> 20:18.000 Let me download it I don't know why it's not playing sorry. 20:18.000 --> 20:29.000 Wait a second okay let's it's downloading okay move hopefully you can play move yeah now it's playing sorry. 20:29.000 --> 20:37.000 Okay we are signing in as a user tester as you can see we have the username tester as well as the email tester yeah. 20:37.000 --> 20:51.000 And here I'm locked in with that I have a kick look session established and now I switch on the kick look side and there I have a setting as very receiver set up for this cable or death environment. 20:51.000 --> 20:58.000 Where I say I'm interested in this events for this particular stream which I set up before hand and so on. 20:58.000 --> 21:03.000 Just to Cape Death and say I want to start transmitting a new event. 21:03.000 --> 21:15.000 And when I click on that transmitting I need to authenticate for this service so load load load. 21:15.000 --> 21:23.000 There is submit my secret access token let's say and there I can select one of the supported Cape events that the service supports in this case. 21:23.000 --> 21:34.000 I want to signal that the session got revoked for some security purposes and here you can see I identified user with subject have email which is different than user name that used to lock in right. 21:34.000 --> 21:38.000 Here I use the email address test that local test let's say. 21:38.000 --> 21:46.000 I sent the Cape event and this basically triggered a push delivery of the security event token. 21:46.000 --> 21:52.000 And if I now switch back to this and reload the page we will see that I'm now signed out. 21:52.000 --> 21:56.000 And this is basically shared sickness framework and action. 21:56.000 --> 22:06.000 So to speak in the live demo I would have showed you that you also see in the events few in kick look that there was a session termination or session event. 22:06.000 --> 22:18.000 The signal via shared signals and so on that you can basically see or administrator could see what actually was the cause of this and so on right. 22:18.000 --> 22:21.000 So that was that. 22:21.000 --> 22:34.000 Yeah with that said I could show you that shared sickness framework is a way to standardize a real time event delivery for identity systems and provides a flexible robust mechanism for sharing. 22:34.000 --> 22:40.000 Yeah those security related events with the mentioned profiles Cape and risk. 22:40.000 --> 22:47.000 Yeah we have this secure push and pull delivery mechanism which effectively web hooks and polling. 22:47.000 --> 22:55.000 And yeah this supports to implement use cases such continuous access evaluation and compromise account mitigation. 22:55.000 --> 23:01.000 And yeah shared sickness framework receiver support is coming to see kick look soon with this. 23:01.000 --> 23:10.000 And once this shared sickness framework receiver support is out as the next step I will work on adding transmitter support. 23:10.000 --> 23:21.000 And the last thing I'd like to ask you is yeah if you're interested in this kind of topic and want to work together with us on this standards. 23:21.000 --> 23:25.000 Please feel free to join the shared sickness framework working group of the open deforestation. 23:25.000 --> 23:30.000 We meet every Tuesday at 7 p.m. 23:30.000 --> 23:38.000 Berlin time let's say and yeah if this is a convenient time zone for you or what of free free to drop in. 23:38.000 --> 23:46.000 And with that said I can say thank you very much for listening to a talk and if you have any questions free free talk. 23:46.000 --> 23:51.000 Thank you very much. 23:51.000 --> 23:56.000 Thank you very much. 23:56.000 --> 24:06.000 We assume connectivity between the receiver and the transmitter. 24:06.000 --> 24:13.000 Yes to some degree of course for push delivery we would expect an active connection there. 24:13.000 --> 24:20.000 But it's up to you to introduce some additional queueing and plumbing in between so you can decouple those parties. 24:20.000 --> 24:25.000 If you have an intermediary receiver in between that just forwards and so on. 24:25.000 --> 24:31.000 And we are the asynchronous mechanism you can also call later if the connectivity is disrupted.