Evaluate Shared Signals Framework (SSF/CAEP/RISC) for JIM #370
Description
Summary
Review the OpenID Shared Signals specifications and evaluate whether JIM could benefit from supporting them, or could help customers solve use cases enabled by these standards.
The three specifications (all finalised in September 2025) are:
- Shared Signals Framework (SSF) — An API for asynchronous communication of security events between transmitters and receivers using Security Event Tokens (SETs). Supports push and pull delivery, OAuth-authorised stream management.
- Continuous Access Evaluation Protocol (CAEP) — An SSF profile enabling real-time communication of access property changes (session revocation, credential changes, device compliance shifts, assurance level updates) to support zero-trust security postures.
- Risk Incident Sharing and Collaboration (RISC) — An SSF profile for sharing security alerts across providers (account compromise, credential stuffing detection, identifier changes, recovery events).
Questions to Answer
- Could JIM act as an SSF Transmitter? — JIM already detects identity lifecycle events (joins, moves, leavers), attribute changes, and sync errors. Could these be surfaced as SSF events to downstream consumers?
- Could JIM act as an SSF Receiver? — Could JIM consume CAEP/RISC events from identity providers (e.g. Entra ID, Google Workspace) to trigger immediate sync or remediation actions rather than waiting for scheduled sync cycles?
- CAEP for real-time access decisions — Would receiving CAEP events allow JIM to propagate access changes (e.g. session revocation, compliance state changes) across connected systems faster than periodic sync?
- RISC for incident response — Could JIM consume RISC events to automatically disable/quarantine compromised accounts across all connected systems?
- Customer demand — Is SSF/CAEP/RISC adoption growing in the government, defence, healthcare, and critical infrastructure sectors that JIM targets?
- Air-gapped considerations — How would SSF work in air-gapped deployments where external transmitters/receivers are unavailable? Could JIM-to-JIM federation be useful?
- Entitlement management integration — Could risk signals received via SSF inform entitlement access decisions, allowing entitlement owners to enforce risk-aware policies on membership and self-service access?
Risk-Aware Entitlement Management
A particularly compelling use case for JIM as an SSF Receiver is feeding real-time identity risk signals into entitlement management decisions. Today, entitlement access policies are typically evaluated against static attribute values that only change at the next sync cycle. SSF would allow JIM to maintain a live risk posture for each identity in the metaverse, enabling entitlement owners and managers to define risk-aware policies.
Use Cases
1. Block self-service sign-up when the user is risky
An entitlement owner configures a policy such as "Users with an active RISC account-credential-change-required event or CAEP credential-change event cannot request access to this entitlement." When a user attempts to sign up through JIM's self-service portal, JIM checks the user's current risk signals and denies the request, explaining that the user must resolve the outstanding risk condition first.
2. Suspend membership when a user becomes risky
An entitlement owner configures a policy such as "Suspend membership if the user receives a RISC account-compromised or CAEP session-revoked event." When JIM receives the signal, it immediately suspends the user's membership in the entitlement — removing their access from downstream connected systems via export — without requiring manual intervention. The entitlement owner is notified and can reinstate when the risk is resolved.
3. Require re-approval for risky users
Rather than outright blocking or suspending, an entitlement owner could configure a softer policy: "If a user's risk level changes, move their membership to a pending re-approval state." This keeps the human in the loop while still reacting in near real-time to risk signals.
4. Risk-tiered entitlement access
Entitlements could be classified by sensitivity (e.g. standard, elevated, privileged). Higher-sensitivity entitlements could require stricter risk thresholds — a user flagged with device-compliance-change might retain access to standard entitlements but have privileged entitlements suspended until the device is compliant again.
5. Correlated risk escalation
JIM's metaverse already correlates identity data across all connected systems. Combined with SSF signals, JIM could detect compound risk conditions that no single source can see in isolation. For example: a RISC account-credential-change-required event from the identity provider, combined with a device compliance failure from the MDM, combined with an anomalous login location — any one signal might be low severity, but together they trigger an automatic suspension of all privileged entitlements.
How This Fits Architecturally
+---------------------+ +---------------------+
| Identity | | MDM / Device |
| Provider | | Compliance |
| (SSF Transmitter) | | (SSF Transmitter) |
+--------+------------+ +--------+------------+
| |
| CAEP/RISC events | CAEP events
v v
+--------+-------------------------+----------------+
| |
| JIM (SSF Receiver) |
| |
| Metaverse Identity |
| +----------------------------------------------+ |
| | User: jsmith | |
| | Risk signals: | |
| | - account-credential-change-required | |
| | - device-compliance-change (non-compliant) | |
| | Risk level: HIGH (correlated) | |
| +----------------------------------------------+ |
| |
| Entitlement Policy Engine |
| +-------------------------------------------+ |
| | "VPN Access" - standard - no restrictions | |
| | "Admin Portal" - privileged - SUSPENDED | |
| | "Code Signing" - privileged - SUSPENDED | |
| +-------------------------------------------+ |
| |
+-------+----------------+--------------------------+
| |
| export | export
v v
+-------+------+ +------+-------+
| VPN / | | Application |
| Network | | Systems |
+--------------+ +--------------+
Key Considerations
- Entitlement owner autonomy — Risk policies should be configurable per entitlement by the entitlement owner/manager, not just system-wide. Different entitlements have different risk tolerances.
- Transparency and auditability — When access is blocked or suspended due to a risk signal, JIM must record the specific signal(s), the policy that triggered the action, and the timestamp. Users and entitlement owners need visibility into why access changed.
- Reinstatement workflow — There must be a clear path to restore access once the risk condition is resolved. This could be automatic (risk signal cleared → membership reinstated) or manual (entitlement owner reviews and re-approves).
- Signal freshness and expiry — Risk signals are point-in-time events. JIM needs a model for how long a signal remains "active" — does an
account-compromisedsignal remain in effect until explicitly cleared, or does it expire after a configurable period? - Graceful degradation — If JIM stops receiving signals (network issue, transmitter outage), it should not silently treat the absence of signals as "no risk." The policy engine needs a stance on signal staleness.
Self-Hosted Zero-Trust Federation
The most strategic opportunity may be JIM's role as the identity signal backbone for a fully self-hosted Zero-Trust federation — something that doesn't exist today outside of cloud ecosystems.
The Problem
Zero-Trust architecture depends on continuous verification: "never trust, always verify." In cloud-connected environments, this is delivered by vendors — Microsoft's CAE, Google's BeyondCorp, Okta's continuous posture evaluation. But in disconnected, air-gapped, or sovereignty-constrained networks (defence, classified government, critical national infrastructure, secure healthcare), organisations are left with:
- Static token trust — tokens are valid until they expire, regardless of what has changed
- No cross-service signal propagation — if an account is disabled in AD, the OIDC provider doesn't know until the next sync cycle (minutes to hours)
- No federated risk sharing — if one application detects a compromised session, other relying parties have no way to be informed in real time
- Vendor lock-in for zero-trust — the only way to get continuous access evaluation today is to use cloud identity platforms, which is not an option for these environments
- No risk-aware entitlement decisions — entitlement access is governed by static attributes; there is no mechanism to factor in real-time risk posture when granting, maintaining, or revoking access
How JIM + SSF Could Solve This
JIM is uniquely positioned to become the missing piece that enables self-hosted Zero-Trust federation, because it already sits at the centre of identity data flow across all connected systems.
JIM as the SSF Transmitter hub in a self-hosted federation:
+-------------------+ +-------------------+ +-------------------+
| On-Prem AD / | | MDM / Device | | HR System / |
| Samba AD | | Compliance | | Authoritative |
+--------+----------+ +--------+----------+ +--------+----------+
| | |
| sync | sync | sync
v v v
+--------+---------+------+--------+---------+------+--------+----------+
| |
| JIM (Metaverse) |
| |
| - Detects identity state changes across ALL connected systems |
| - Correlates events (account disabled + device non-compliant + ...) |
| - Emits SSF events (CAEP + RISC) as a Transmitter |
| - Receives SSF events and applies risk-aware entitlement policies |
| |
+-------+----------------+----------------+----------------+------------+
| | | |
| CAEP/RISC | CAEP/RISC | CAEP/RISC | CAEP/RISC
v v v v
+-------+------+ +------+-------+ +----+--------+ +----+-------------+
| Keycloak / | | Application | | API | | Other JIM |
| OIDC | | Gateway / | | Gateway | | Instance |
| Provider | | Reverse | | | | (SSF Receiver) |
| | | Proxy | | | | |
+--------------+ +--------------+ +-------------+ +------------------+
What this enables:
- Immediate token invalidation — JIM detects an account disabled in AD during sync, emits a CAEP
session-revokedevent, and the self-hosted Keycloak instance invalidates all active tokens for that user within seconds — not at the next token refresh. - Cross-system risk correlation — JIM's metaverse sees changes across all connected systems simultaneously. If an account is disabled in AD and a device is marked non-compliant in the MDM and the HR system shows the user as a leaver, JIM can emit a correlated high-severity RISC event rather than three separate low-level signals.
- Federated signal propagation across sites — In multi-site deployments, one JIM instance could transmit SSF events to another JIM instance acting as a receiver. This creates a self-hosted federation mesh where identity signals propagate across network boundaries without requiring cloud connectivity.
- Application-level zero-trust — Beyond token issuers, application gateways and reverse proxies that support SSF Receiver could consume JIM's events directly, enabling per-request access decisions based on real-time identity state (e.g. blocking API calls from a user whose clearance level just changed).
- Risk-aware entitlement management — Entitlement owners can define policies that automatically gate, suspend, or revoke entitlement membership based on real-time risk signals — closing the gap between "identity is compromised" and "access is removed" from hours to seconds.
- Audit and compliance trail — SSF events are structured, timestamped Security Event Tokens (SETs). JIM emitting these creates a standards-based audit trail of every identity signal that influenced access decisions — valuable for compliance in regulated sectors.
Why This Matters
No self-hosted product currently offers this. Organisations running disconnected networks today must choose between:
- Accept the risk of stale tokens and delayed propagation
- Build custom integrations between each system (expensive, fragile, non-standard)
- Connect to the cloud (not possible for classified/air-gapped environments)
JIM + SSF could offer a fourth option: standards-based, self-hosted Zero-Trust federation powered by the identity signals JIM already generates. This positions JIM not just as an identity synchronisation engine, but as critical zero-trust infrastructure for disconnected networks — with entitlement management as a key enforcement point for risk-driven access control.
Key Questions
- What self-hosted OIDC providers currently support or plan to support SSF Receiver capabilities? (Keycloak has had community discussion around this)
- Would JIM need to implement the full SSF Transmitter spec, or could a lightweight event webhook approach achieve similar results with less complexity as a stepping stone?
- How would JIM handle event delivery guarantees in environments where receivers may be temporarily unreachable (push vs pull trade-offs, event replay/catch-up)?
- Could JIM-to-JIM SSF federation work for multi-site deployments where identity signals need to cross network boundaries?
- Should JIM also act as an SSF Receiver to consume events from applications (e.g. an application detecting anomalous behaviour) and propagate those signals back through the federation?
- Could this become a differentiating capability that positions JIM as essential infrastructure for zero-trust in disconnected networks?
- How should risk signals be modelled on metaverse objects — as transient event state, computed attributes, or a dedicated risk profile?
- What is the right default behaviour for entitlement policies when no risk signals are present (open by default vs. require explicit "clean" signal)?
Resources
- Specifications: https://openid.net/wg/sharedsignals/
- Developer guide: https://sharedsignals.guide
- CAEP developer resources: https://caep.dev