SGNL welcomes the publication of the final Shared Signals and CAEP specifications!

Today, the OpenID Foundation announced the approval and publication of the final specifications for the Shared Signals Framework (SSF), Continuous Access Evaluation Profile (CAEP), and the Risk Information Sharing and Coordination (RISC) specifications. This represents an important industry milestone in achieving continuous identity security.

What are these specifications?

SSF: The Shared Signals Framework provides a robust mechanism for asynchronous delivery of security event tokens (SETs). It also provides mechanisms for SET transmitters and receivers to negotiate event types, delivery mechanisms, and subjects, as well as to manage and verify the streams.

CAEP: The Continuous Access Evaluation Profile specification defines specific event types (i.e. types of SETs) that are useful in communicating changes to live sessions that logged in users have with services they use. These events are sent and received using SSF.

RISC: The Risk Information Sharing and Coordination specification defines specific event types that are useful in communicating account security changes between services that share users. These events are sent and received using SSF.

Why does it matter?

Before CAEP was envisioned in a blog published by Google in February 2019, services that logged in users using a federated identity token had no means of getting updated about changes at the identity provider. To remedy this situation, they used one of three mechanisms:

• Continuous Authentication: The service relying on the federated identity token would keep the local session lifetime short. The user would be bounced back to the IdP that issued the token every hour or so in order for the IdP to re-issue the token (assuming it would re-evaluate the validity parameters that permitted the login in the first place), or it would force the user to re-authenticate. This was disruptive to the user experience, and as remote work became the norm, this became hugely taxing on the identity provider.
• Validation Proxy: Organizations wanting to make sure user access could be terminated in real-time would force users to go through special network proxies so that each access is validated in real-time. The validation proxy could not provide contextual decisions, and so largely had to determine access based on slower moving data. It also added to the fragility and latency in accessing services.
• Proprietary APIs: Service providers would expect identity providers to write to their proprietary APIs to communicate any changes subsequent to the user login. While this was possible for some of the largest service providers, it wasn’t an option for others.

CAEP (along with SSF) creates an asynchronous mechanism for such session changes to be communicated, not just between an identity provider and a service provider, but also between various other services that can impact the session state:

• A device management service may detect that the user’s device is no longer compliant
• A XDR service may discover issues with a user or their device’s security
• An application may discover anomalous behavior.

With CAEP, all parties that share the same user can communicate these changes asynchronously. This now makes continuous identity security possible because any change that impacts a user’s session anywhere can be instantaneously communicated to every system that needs to know about it.

SGNL’s leadership

SGNL CTO, Atul Tulshibagwale, invented CAEP when he worked at Google. He has been a co-chair of the Shared Signals Working Group (SSWG) in the OpenID Foundation since the informal CAEP working group merged with the OpenID RISC working group to form the SSWG. Under his leadership and evangelism, SSF and CAEP have been adopted by leading companies including Apple, IBM, Jamf, Okta, Omnissa, SGNL and others. SGNL also operates the caep.dev website that offers resources for developers to test their CAEP implementations and to learn about these protocols.