Continuous access signals: CAEP and the Shared Signals Framework in Monokee

What this covers

A session that was legitimate this morning may not be legitimate this afternoon: the laptop falls out of compliance, the contract ends, a credential is changed elsewhere, a risk score moves. Federation protocols have no way to say so — a token, once issued, is simply honoured until it expires.

The Shared Signals Framework (SSF) is the answer to that: a standard way for identity systems to tell each other, continuously, that something has changed. CAEP and RISC are the two vocabularies spoken over it — CAEP for continuous access evaluation, RISC for account-level risk.

Monokee implements both roles: it emits signals about what happens in it, and it consumes signals emitted by others.

Availability. The capabilities described here ship with Monokee 6.0, scheduled for the end of September 2026. The implementation currently passes the official OpenID Foundation Shared Signals conformance test suite; formal certification is released with that version.

Architecture

Three components, deliberately separated so that producing an event, distributing it and speaking the protocol are three different jobs:

The separation is what lets Monokee act as an event source, a Transmitter, a Receiver or any combination of the three without changing the microservices that generate the events. A deployment that only needs to emit signals does not carry the receiver, and a deployment that later needs to consume them does not have to revisit anything upstream.

Design principles

• One place where events are defined. Every microservice emits to the same component. No service invents its own event semantics, which is what usually turns an event stream into a set of dialects.
• Append-only. Once accepted, an event is never modified or deleted. The store is queryable, so the same data serves operations and forensics without a separate export.
• Schema-governed. Event types are declared centrally and every event is validated against its type on the way in. An invalid event is rejected at the boundary and surfaced to the producer, rather than being stored and found later.
• Pluggable distribution. Outbound publication and inbound ingestion sit behind two interfaces, EventPublisher and EventSubscriber, so a new transport or destination does not touch the event pipeline or the protocol layer.
• Multi-tenant by construction. Every event carries its domain, and stream configuration, receiver registration and event visibility are scoped to it.

Event management

monokee-event-core is the system of record for everything the platform produces.

• Event types. The Monokee-native types plus the standard CAEP and RISC types, each declared with the structure its payload must respect.
• Ingestion. Microservices submit events over HTTP. The same API is open to other producers: third-party systems can create events directly, and a step of an orchestration flow can raise one — so any point of an identity journey can emit a signal without integration code written for the purpose.
• Retrieval. Events are queried and filtered with SCIM-style filter expressions, the same as the rest of the Monokee resource model.
• Publication. Accepted events go out through EventPublisher. Today the single implementation writes to an internal queue, which the transmitter layer reads.

On the roadmap. EventPublisher is designed for several implementations at once. The near-term goal is to publish the same validated stream to SIEM and SOAR platforms in parallel with the SSF transmitter — without duplicating event production in the emitting services.

Transmitter

• Several transmitters per deployment, each responsible for a defined set of event types — a CAEP session-management transmitter and a RISC account-events transmitter can be exposed independently, each with its own configuration and its own receivers.
• Pluggable ingestion. Each transmitter has an EventSubscriber that decides where its events come from. Today that is the internal queue; additional subscribers — direct HTTP ingestion from outside — let a transmitter relay events Monokee did not itself generate.
• Receiver registration, with the stream configuration and delivery method agreed with each receiver.
• Full protocol: transmitter metadata, stream creation, configuration, status and verification, subject management, and delivery as signed Security Event Tokens.
• Delivery accounting. Every event is tracked per transmitter, per stream and per receiver, so “was it delivered” is a question with an answer.

Receiver

• Several receivers, defined as first-class configurable entities, with external transmitters registered against them.
• Declarative stream lifecycle. Streams are defined in Monokee; on creation and update the receiver calls the remote transmitter’s stream management API to create and maintain the stream on the other side. Configuration is driven from Monokee rather than managed out of band on each transmitter.
• Inbound tracking. Everything received from every registered transmitter is recorded — a complete inbound audit trail.
• Forwarding to orchestration. A received event can be forwarded into a Monokee flow. This is the part that matters: an inbound signal becomes a trigger, not a notification.

Standards

The implementation targets the OpenID Foundation Shared Signals specifications, approved as Final Specifications in September 2025:

• OpenID Shared Signals Framework 1.0 — Transmitter and Receiver roles, stream management API, delivery methods.
• OpenID CAEP 1.0 — continuous access evaluation events: session revoked, credential change, assurance level change, device compliance change and related.
• OpenID RISC 1.0 — account-level risk and security events.
• RFC 8417 (Security Event Token), RFC 9493 (Subject Identifiers for SETs), RFC 8935 (push delivery), RFC 8936 (poll delivery).

Work is also aligned with the CAEP Interoperability Profile 1.0 as it moves toward final status.

Why the orchestrator is the point

Most implementations of continuous access signals end in a console. Something is received, something is displayed, and a human decides what to do about it.

Here the receiver forwards the event into the orchestration engine, so an external signal is composed with Monokee’s own identity logic — policy evaluation, session termination, step-up authentication, entitlement revocation, downstream provisioning — using the same visual model as every other identity journey. The reaction to a signal is a diagram somebody can read, not code somebody has to maintain.

In the other direction, identity lifecycle changes generated anywhere in Monokee are normalised, validated and made available to any registered external receiver as standard SSF events.

Monokee is both a producer and a consumer of continuous access signals, and the orchestration layer is what closes the loop between the two.

Where to go next

The evaluation model these signals feed is described on Adaptive Access, the composition layer on Visual Identity Orchestrator, and the wider protocol surface on Standards & protocols.