Shared Signals Working Group - Overview
What is Shared Signals Working Group?
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.
- 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.
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.
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 Implementer’s draft of the RISC Profile specification.
SSF Explainer Video
Working Group Chairs
News, Events and Presentations
What’s New in the Shared Signals Framework? blog explaining how the new Implementer’s Draft how is different from the previous version. (November 3, 2023)
- SGNL launched caep.dev, a free online CAEP Transmitter, in partnership with the OpenID Foundation
- 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.