Yeah, thanks everyone and good morning.
My name is Thomas and I'd like to give you a brief introduction to the shared signals framework as introduced.
First of all, me, the self-employed identity consultant,
I love digital identity and standards.
I'm involved with some open-source projects and I'm also one of the maintainers of the Kiko project.
And I also work at the Open Adi Foundation in the certification team where I develop
conformal testing software for internet identity protocols.
Like, open the Connect Fabi2, Open Adi for verifiable credential issuance and, of course, Shedsignance framework.
Speaking of which, maybe brief description about it.
What is the shared signals framework in a nutshell?
The shared signals framework is a protocol that provides a standardised way for identity systems
to communicate events in a trusted way between parties to improve security and user experience.
It's governed by the Open Adi Foundation and we are the shared signals framework working group.
It's an open working group. You are all free to join if you're interested in that topic.
And its main goals are to enable real-time communication of critical security events
and to reduce complexity by standardising event formats and delivery mechanisms
to enhance interoperability across identity systems.
Giving you a small example. If you think of a scenario where you have a thus application and some connected identity provider,
you can imagine that when users use the system, there might be different things occurring
that the particular application or system can observe.
Use the abnormal user behavior, maybe some threat detection kicks in, or some user posture,
how it is using the system indicates some abuse.
Also, identity providers that might be used with us systems might produce their own sort of a set of signals to indicate problems,
like different devices suddenly being used.
The user performed an impossible travel or something like that.
Or we detect a user risk-scoring detected some issues or IP enrichment or IP reputation data
was taken into account and we detected that the user came from a suddenly comes from an IP that has
known buttoned buttoned behaviors.
All those different signals comes in different forms of shapes depending on the product that emittered up.
And shared signals now tries to uniform and normalise those events such that you can enable continuous access evaluation,
really detect, unauthorised access, credential theft, data, exploitation, or letter-remoofment or even privileged escalations.
And let's see how that works.
Give you some additional use case examples here.
For one use case could be that you want to perform real-time session replication.
So if an identity provider detects that some account got compromised or has some other issues,
they can signal all the relying parties about it.
And maybe they can then revoke the sessions of the current user.
Or we can detect that an account is compromised and we can then trigger the development of sensitive applications.
Accounts let's say.
Or we can help with automatic user deep provisioning that upon termination of a user account,
we can help systems prevent off-and-accounts that keeps the active even though the user is already deactivated.
And other systems.
What are the building blocks of shared signals framework?
Let's see, of course, first of all we have to secure it event.
This is basically an event resulting from some observed behavior of a user, a system, or a device, or a combination of it.
Then we have a thing called the transmitter.
The transmitter is a system embedding a security event.
For instance, could be an identity provider.
Then the events, security events, it middard, are then received by a component called the receiver.
The receiver is a system consuming the security event.
For example, a source provider or any relying party is included.
And of course those events are managed in a logical subscription that we call stream.
And this is basically grouping certain security events that are received as interested in, which are managed by the transmitter.
So, to illustrate that in the graphic, imagine we have a shared signal framework transmitter.
And we have a shared signal streaming receiver.
And the receiver basically creates a stream on the transmitter, like a subscription, which tells the transmitter.
By the way, this receiver is interested in this sort of security related events.
And then, once the transmitter emits those events, there are many different ways this events can be transported.
One of those methods is an async transport, so to speak.
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.
And that contains information about the subject and the event, let's say, that was the cause of that particular security event.
The shared signal streaming protocol stack uses a set of well-established standards, like for instance, the JSON object signing and encryption.
So, that's for JSON web token, JSON web signature and so on.
Building up on that, we have the security event token, which is the signed dot that carries on the event information.
Then we have to push to delivery methods, push and pull methods, and standard to identify identities, so to speak.
And on those pillars, we have then the shared signals framework.
Shared signals, very basically combines all those underlying protocols and prescribes how to set up a set from a transmitter and receiver.
What metadata is provided and what inputs and points it to be provided in order to interact.
And we have some profiles on top of that, with Cape and Risk, we'll explain later what it is.
Those describing basically a set of use cases and events that are carried over this shared signals mechanism.
Let's see, in more detail.
First, the security event token, or abbreviated as a set, so to speak, this is IRC 8417.
It's a set of JSON web token based format for conveying security related events.
It includes a standardized event type with an event specific payload, with a subject identifier, and some metadata.
The security event token is basically signed by the transmitter for non-reputation in the security protection, and of course verified by the receiver.
The subject identifier is using this IRC 9493, and that's a standardized way to reference identities across systems.
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.
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.
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.
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.
And in the payload we have of course the issue of this particular event which is the transmitter, of course.
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.
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.
And of course it is signed with some kind of JSON website signature.
That's it.
For describing those events, there are two profiles as set.
One is basically cape, cape is abbreviation for continuous access evaluation profile, and was initially defined by Google.
And this is basically as a profile that enables continuous monitoring and evaluation of access decisions based on sessions.
So an example events that this profile brings are for instance session revoked, token clips changed or risk level changed.
Next to that we have a risk profile which is sending for risk and incident sharing and coordination.
This profile is basically more focused on disaster mitigation and related to security risk and incidence of user accounts of real accounts.
And example events are credentialed compromise, credentialed change required or account is able to answer on.
And first there are some other profiles as you will see in a bit.
And yeah, but this are the most commonly used ones.
And just give you some more examples what kind of events you can express with this profiles.
A set session revoked of course to have some kind of glorify global lockout capability.
But others also include device compliance changed.
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.
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.
Just to give you a few examples.
Yeah, how can this sets be delivered.
I've said we have two methods. First one is push delivery method which is all the standardized on ROC 89 35.
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.
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.
And this basically enables you real time event delivery as the event occurs.
There's also the Paul delivery method which is based on ROC 89 36.
And this is basically the transmitter providing a Paul endpoint.
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.
That you can receive multiple security events at once.
Yeah, and I said this is just an example how delivery we are push on delivery we are Paul would work.
The transmitter would hold the stream definitions and queue some events for particular stream.
And in the case of push they would basically just call the push end point and acknowledge the received of this event.
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.
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,
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.
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.
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.
On top we have the continuous access evaluation profile actually for session related events.
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.
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.
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.
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.
Some of you one of the obvious use cases of course to use kick-up as a shared sequence framework transmitter.
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.
Suspension or password credential changes or whatnot.
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.
We also need to support some kind of queuing mechanism and so on and this is a bit more involved getting into kick-up.
And of course we need to pulling and pushing for structure to reliably deliver this events.
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.
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.
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.
And this is what I will demonstrate to you in a second.
First I want to introduce you to CapeDev, Cape.Dev is a free website and implementation of shared sequence framework.
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.
As I said adding this to kick-up is a bit involved because you need some additional infrastructure plumbing to get us all going.
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.
Yeah identity related structures like clients identity providers and so on and users and so on.
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.
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.
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.
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.
And what the demo shows here first we lock in as a user to is it running no.
But we lock in as a user tester to a second page app let's say that secured my kick lock.
I need to click play yeah.
No it's not playing great right second this played right okay okay.
Let me download it I don't know why it's not playing sorry.
Wait a second okay let's it's downloading okay move hopefully you can play move yeah now it's playing sorry.
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.
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.
Where I say I'm interested in this events for this particular stream which I set up before hand and so on.
Just to Cape Death and say I want to start transmitting a new event.
And when I click on that transmitting I need to authenticate for this service so load load load.
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.
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.
Here I use the email address test that local test let's say.
I sent the Cape event and this basically triggered a push delivery of the security event token.
And if I now switch back to this and reload the page we will see that I'm now signed out.
And this is basically shared sickness framework and action.
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.
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.
So that was that.
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.
Yeah those security related events with the mentioned profiles Cape and risk.
Yeah we have this secure push and pull delivery mechanism which effectively web hooks and polling.
And yeah this supports to implement use cases such continuous access evaluation and compromise account mitigation.
And yeah shared sickness framework receiver support is coming to see kick look soon with this.
And once this shared sickness framework receiver support is out as the next step I will work on adding transmitter support.
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.
Please feel free to join the shared sickness framework working group of the open deforestation.
We meet every Tuesday at 7 p.m.
Berlin time let's say and yeah if this is a convenient time zone for you or what of free free to drop in.
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.
Thank you very much.
We assume connectivity between the receiver and the transmitter.
Yes to some degree of course for push delivery we would expect an active connection there.
But it's up to you to introduce some additional queueing and plumbing in between so you can decouple those parties.
If you have an intermediary receiver in between that just forwards and so on.
And we are the asynchronous mechanism you can also call later if the connectivity is disrupted.