The Shared Signals Framework (SSF) improves API efficiency and security by providing privacy-protected, secure webhooks. It is in use by some of the largest cloud services to communicate security alerts and status changes of users, continuously and securely to prevent and mitigate security breaches. It is currently leveraged by two applications – the Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC) to achieve this result.
- A free, non-commercial online CAEP Transmitter was launched by SGNL in partnership with the OpenID Foundation. Visit caep.dev for more details.
- Working Group renamed to “Shared Signals Working Group” from “Shared Signals and Events Working Group”
- Guest blog by Shared Signals working group members published by the Identity Defined Security Alliance (IDSA) – Securing Cloud Access with Continuous Access Evaluation Protocol (CAEP)
- The Second Implementer’s Draft for the OpenID RISC Profile Specification has been approved.
- Panel on SSF at Identiverse 2022: YouTube video
- Cisco launches a website dedicated to SSF: sharedsignals.guide
- Read the blog post that explains the Shared Signals Framework: Shared Signals: An Open Standard for Webhooks
- CAEP on the Identity Unlocked podcast: Continuous Access Evaluation Protocol (CAEP) with Tim Cappalli and Atul Tulshibagwale
- The Implementer’s Drafts for the Shared Signals and Events Framework Specification and the Continuous Access Evaluation Profile Specification are now approved.
SSF Explainer Video
What is the Shared Signals Framework?
The Shared Signals Framework is:
- An API that facilitates asynchronous communication between Transmitters and Receivers. It features:
- Describe a Transmitter to anyone, including endpoints and supported event types
- Securely establish a stream with a subset of supported event types, requested by a Receiver and agreed to by a Transmitter
- Securely manage the stream including start, pause and delete the stream
- Add or remove subjects of interest in the stream, a subject can be defined as narrowly or broadly as desired.
- Events in the stream relate to subjects that are of mutual interest
- A subject may provide consent to being included in the stream (if applicable)
- Send and receive events using a push or pull model based on IETF standard protocols
- The API can be authorized using OAuth or other means
- The streams contain discrete events formatted as SETs
- SSF events use IETF SecEvents Subject Identifiers within the SETs.
Read the implementers’ draft of the Shared Signals Framework specification here.
The Shared Signals Framework may be profiled for specific applications. Current applications include the Continuous Access Evaluation Profile (CAEP) and Risk Incident Sharing and Coordination (RISC)
Continuous Access Evaluation Protocol (CAEP)
Federated systems are a common way of enforcing access control. Widely used federated identity standard protocols such as SAML and OpenID Connect enable identity providers to assert the validity of access at the time of user login. These sessions may last over long durations of time, often several days during which time the user properties, such as location, authentication or organizational membership may have changed. So relying on information that was only asserted at the time of login creates security issues due to unauthorized access that is provided based on the old information. Therefore, a standards-based approach to communicating changes to access properties is proposed through this working group. CAEP is a standardized way to describe status changes. CAEP events, expressed as security event tokens (SET) are sent by Transmitters using the SSE framework. Once a CAEP event is received, the Receiver can take appropriate security measures to ensure dynamically adjust the user’s privacy and security access posture. This makes CAEP a cornerstone of zero-trust security.
CAEP (previously known as the Continuous Access Evaluation Protocol) was first proposed in a blog post by Google. A number of companies have contributed to its development and its independent standardization effort was merged into this working group of the OpenID Foundation.
- CAEP is specified as a profile of the SSE Framework that facilitates zero-trust security
- CAEP includes events such as:
- Session Revoked
- Token Claims Change
- Credential Change
- Assurance Level Change
- Device Compliance Change
- Read the implementers’ draft of the Continuous Access Evaluation Profile specification.
Risk Incident Sharing and Coordination (RISC)
Attackers often target multiple accounts across service providers for a single individual, knowing that users normally register for all their internet services with just a few email addresses. This kind of account takeover attacks are called credential stuffing attacks. For example, a victim’s social networking account may send password recovery information to their email account, or they might log into her photo sharing account using their social network credentials. When criminals exploit these linkages, a single weak link can create a cascade of account takeovers.
The Risk & Incident Sharing and Collaboration (RISC) provides a standardized way to transmit and receive security alerts about such attacks. It enables providers to prevent attackers from compromising linked accounts across multiple providers and coordinate in restoring accounts in the event of compromise.
- A profile of the SSE framework to improve account security
- Includes events such as:
- Account Credential Change Required
- Account Purged/Disabled/Enabled
- Identifier Changed/Recycled
- Credential Compromise
- Recovery Activated/Information Changed
- Read the draft RISC Profile specification.
List of Specifications
Working copies of the specification can be found in the group’s repository.
The easiest way to participate is to join the mailing list at https://lists.openid.net/mailman/listinfo/openid-specs-risc.
Please note that while anyone can join the mailing list as a read-only recipient, posting to the mailing list or actively contributing to the specification itself requires the submission of an IPR Agreement. More information is available at http://openid.net/intellectual-property. Make sure to specify the working group as “Shared Signals and Events”.
- When: Tuesdays 6pm UTC
- Where: https://zoom.us/j/98105195621?pwd=MjJmUUJ2dW9zRVp3NWtDQ3RpTzRadz09
- Meeting Notes: https://bitbucket.org/openid/risc/wiki/Home
- When: Tuesdays 6pm UTC