The Shared Signals Framework is an OpenID Foundation specification for asynchronous, privacy-protected security webhooks between a Transmitter and a Receiver — a standard way for one service to tell another that a session was revoked, a credential changed, a device fell out of compliance, or an account was compromised. Two profiles build on it — the Continuous Access Evaluation Protocol (CAEP) for zero-trust session and device events, and Risk Incident Sharing and Coordination (RISC) for account takeover and credential compromise. All three reached Final Specification status on 2 September 2025.
Shared Signals Framework
The Shared Signals Framework answers a question every federated system eventually hits: you issued a token that is good for an hour, and forty minutes in the user was fired, the device was jailbroken, or the credential turned up in a breach dump. Nothing in OAuth or OpenID Connect tells the relying party. SSF is the out-of-band channel that does — a Transmitter pushes Security Event Tokens to a Receiver’s stream, and the Receiver acts.
- A Transmitter/Receiver stream, not polling - Configuration, verification and delivery of signed Security Event Tokens, with the subject identified in a privacy-preserving form rather than by broadcasting user data to everyone subscribed.
- CAEP — the zero-trust profile - Session revoked, credential change, device compliance change, assurance level change. This is the profile that turns a long-lived grant into one that can be pulled back mid-flight.
- RISC — the account-security profile - Account credential compromised, account disabled, identifier recycled. Aimed at coordinated response to takeover across providers.
- Final, not draft - SSF, CAEP and RISC were all approved as Final Specifications on 2 September 2025, which puts this ahead of most of the agent-identity stack in maturity.
It lands in an API catalog because of what happens when the token holder is an agent. The IETF agent authentication and authorization framework makes observability a security control rather than an operational nicety, and it points at SSF with CAEP or RISC as the mechanism: any participant MAY subscribe, and on receiving a revocation or risk signal the recipient SHOULD attenuate — drop cached tokens, re-acquire with tighter constraints, re-run policy — and MUST NOT keep using authorization that has been withdrawn. An agent working autonomously through a long task is precisely the caller for whom “the token is still valid for another 40 minutes” is the wrong answer.
For providers, this is the piece that makes revocation real rather than nominal. Most API programs today have exactly one revocation story — rotate the key and hope every integration notices — and that story gets considerably worse when the integration is software that will keep retrying. Publishing a signals stream is a bigger commitment than publishing a metadata document, and it is the one control in the whole agent-auth composition that governs what happens after you have already said yes.
