Shared Signals – A Secure Webhooks Framework

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.

What’s New?

SSF Explainer Video

Courtesy: Cisco

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

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.

In summary:

    • 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

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

Co-Chairs

Atul Tulshibagwale (SGNL)

Tim Cappalli (Microsoft)

Annabelle Richard (Amazon Web Services)

List of Specifications

Working copies of the specification can be found in the group’s repository.

Participation

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”.

Meeting Venue and Schedule