Shared Signals Framework (SSF, CAEP and RISC)

What it is

The Shared Signals Framework (SSF) is the OpenID Foundation standard for sending security events between cooperating systems as they happen. A transmitter (an identity provider, an EDR tool, a SaaS app) publishes events about a subject (a user, session, device or token), and receivers that subscribed to an event stream act on them: end a session, force reauthentication, disable an account. It replaces the polling and long token lifetimes that leave a fired employee or a stolen session active for an hour or a day after the IdP knows.

SSF is a profile of IETF Security Event work. Each event is a Security Event Token (RFC 8417), subjects use Subject Identifiers (RFC 9493), and delivery uses push (RFC 8935) or poll (RFC 8936). Two companion specifications define what the events mean: CAEP, the Continuous Access Evaluation Profile, and RISC, Risk Incident Sharing and Coordination. Glossary versions: Shared Signals Framework, CAEP, RISC, Security Event Token.

Status (November 2026)

All three are OpenID Final Specifications, published 29 August 2025:

• OpenID Shared Signals Framework Specification 1.0
• OpenID Continuous Access Evaluation Profile 1.0
• OpenID RISC Profile Specification 1.0

The Foundation announced the approval on 16 September 2025. A Final Specification is not revised further, so this is among the most settled of the agent-relevant standards on this site. The working group's page, read 5 November 2026, lists a CAEP Interoperability Profile at Implementer's Draft stage, and the Foundation said in September 2026 that a self-certification test suite would launch that autumn. We could not confirm it had launched.

How it works

Discovery. A transmitter publishes metadata at /.well-known/ssf-configuration: its issuer, jwks_uri for signature keys, delivery_methods_supported, and the management endpoints (configuration_endpoint, status_endpoint, add_subject_endpoint, remove_subject_endpoint, verification_endpoint).

Stream setup. The receiver calls the configuration endpoint, authorized with OAuth or another method the transmitter names, to create a stream. It chooses the delivery method (urn:ietf:rfc:8935 for push, with its own endpoint_url, or poll) and the events_requested. The transmitter assigns a stream_id. The receiver can then add or remove subjects and ask for a verification event to prove the pipe works end to end.

An event. When an admin revokes a user's sessions at the IdP, the IdP sends each receiver a signed SET like this (simplified from CAEP 1.0):

{
  "iss": "https://idp.example.com/",
  "aud": "https://app.example.com/caep",
  "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
  "iat": 1615305159,
  "sub_id": { "format": "email", "email": "ada@example.com" },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "event_timestamp": 1615304991
    }
  }
}

The receiver verifies the signature against the transmitter's keys, finds the matching sessions, and ends them. With the same pattern a RISC account-disabled event (optional reason hijacking or bulk-account) tells every connected app to treat the account as disabled.

The event vocabularies. CAEP 1.0 has 8 event types: session revoked, token claims change, credential change, assurance level change, device compliance change, session established, session presented and risk level change. RISC 1.0 has 14, covering account credential change required, account purged, disabled and enabled, identifier changed and recycled, credential compromise, the opt-in and opt-out family, recovery activated, recovery information changed and sessions revoked.

What it solves for AI agents and SaaS

For SaaS and workforce identity, SSF closes the gap between "the IdP knows" and "the app acts". Without it, revoking a user at the IdP ends new logins, but sessions and access tokens already issued to apps stay valid until they expire. NIST IR 8587 (September 2026), Protecting Tokens and Assertions from Forgery, Theft, and Misuse, names SSF and CAEP and says cloud service providers and consuming agencies "SHOULD implement session revocation signals". It also notes "the SSF has seen significant adoption".

SSF is also the receiving end for ITDR and conditional access: a detection in one tool becomes a session termination in many apps within seconds, which matters most for session-cookie and token theft, the paths where MFA has already been passed (see session cookie theft and refresh token abuse).

For AI agents, SSF is the only Final standard that can revoke access mid-task across many resource servers. Model each agent as its own subject, subscribe every tool and MCP server it can reach as a receiver, and send session-revoked or account-disabled when the agent is disabled, its owner leaves, or its behavior trips a detection. The gap, recorded in SWI's Agent Identity Standards Map 2026: none of the 22 event types describes "this delegation grant was withdrawn" or "this agent was disabled", so agent semantics are a deployment convention, not a standard. The IETF AIMS draft recommends SSF for agents on that basis.

Adoption signals (verified)

• The OpenID Foundation's September 2025 release states that "Apple, IBM, Okta, and others, have already adopted these protocols."
• The specification authors work at SGNL, Okta, Coinbase, Amazon, Yubico, Cisco, Oracle and VeriClouds, per the published Final texts.
• caep.dev, a free online CAEP transmitter launched by SGNL with the working group, is linked from the working group page for testing receivers.
• NIST IR 8587 recommends session revocation signals using SSF and CAEP.

We list only what a primary source confirms. Many IdPs and ITDR tools market "shared signals" support; check for the OpenID event type URIs and stream management API rather than the phrase.

How to implement or evaluate

1. Start as a receiver in your most sensitive app: accept session-revoked and credential-change from your IdP and end matching sessions. This is where most value lands first.
2. Ask vendors precise questions: which SSF version, push or poll, which CAEP and RISC event types they transmit and receive, which subject identifier formats, and how long from event to enforced session end.
3. Use short access tokens anyway. Signals reduce exposure; they do not replace expiry. Pair them with RFC 7009 refresh-token revocation.
4. Verify the stream. Use the verification endpoint on a schedule and alert when a stream stops delivering. A silent broken stream looks exactly like a quiet day.
5. For agents, give each agent a stable subject identifier, register it with every receiver, and document your mapping (for example: agent disabled maps to RISC account-disabled).

Pitfalls

• Subject mismatch. The transmitter's identifier (email, iss+sub, opaque) must resolve to the receiver's account. Agree on formats up front.
• Receivers that log but do not act. Test that a session-revoked event actually ends a live session.
• Unauthenticated push endpoints. Validate signatures and aud on every SET, or an attacker can send fake revocations or block real ones.

Related

MCP authorization, AuthZEN, OAuth Transaction Tokens, ID-JAG and Cross App Access, the securing AI agent identities guide, and the Identity Breach Report 2026 for how often sessions and tokens outlived the response. Glossary: token theft, MFA blind zone.

Who wrote it

SSF is edited by Atul Tulshibagwale, Tim Cappalli, Marius Scurtescu, Annabelle Backman, John Bradley and Shayne Miel. RISC adds Phil Hunt and Stan Bounev among its authors. More in the experts directory.