Most cyber attacks leverage identities. These standards are our best defense against such attacks.

Co-authored by Atul Tulshibagwale, CTO of SGNL, Co-chair of Shared Signals Working Group, and Corporate Board Member of OpenID Foundation, and Omri Gazitt, co-founder & CEO of Aserto and co-chair of AuthZEN Working Group.

These days, most cyber attacks compromise employee identities to breach organizations. To protect against these attacks, it is critical for all cloud services to have the latest information about each session. Instant information sharing enables making access decisions that allow access to legitimate users, while blocking attackers who attempt to impersonate legitimate users. CAEP, SSF and AuthZEN are standards that can help achieve this. Read the blog below to learn how.

At the recently concluded Gartner IAM Summit in London, the OpenID Foundation hosted two interoperability events. One focused on CAEP and SSF, and the other focused on AuthZEN. A question that some attendees of the conference, and those who came to see the interoperability demos, asked was, “do CAEP and AuthZEN compete with each other?”. The short answer is no, they provide complementary functionality to make dynamic authorization decisions. Read the rest of this blog to learn how.

What are CAEP and AuthZEN?

Continuous Access Evaluation Protocol / Profile (CAEP)

CAEP, which stands for the “Continuous Access Evaluation Protocol” (or “Continuous Access Evaluation Profile” when referring just to the specification) is a means of conveying events that impact the properties of logged in sessions. The Shared Signals Framework (SSF) provides a robust and rich asynchronous event transport, and the CAEP specification defines the events which affect session properties. So while transmitters and receivers can use SSF to create, pause and delete streams of events between them, the CAEP spec defines events such as “session revoked”, “token claims change” or “device compliance change”, which can communicate changes in session state. Together, SSF and the Continuous Access Evaluation Profile form the Continuous Access Evaluation Protocol. To be clear, SSF is not just used for CAEP, it is also used for communicating account security events through RISC (Risk Information Sharing and Coordination), and can be used as a transport for SCIM Events which convey account updates. Shared Signals is a foundational standard, and just like we are seeing large scale adoption of CAEP and RISC, we expect more profiles to be created on top of SSF for various specialized purposes. 

The following diagram describes a typical CAEP architecture:

Source: SGNL)

AuthZEN

NIST has defined an externalized authorization model in their SP 800-162 publication (sometimes referred to as the “P*P” model), which can be used to externalize authorization decisions from an application or service. This architecture is described in the diagram below:

(Source: Aserto)

In the above diagram, when a user requests a resource (arrow 1), the application, acting as a Policy Enforcement Point (PEP), delegates the decision (arrow 2) to a Policy Decision Point (PDP). The PDP consults policies (arrow 3) that are managed offline by a Policy Administration Point (PAP). A Policy Information Point (PIP) provides data that is required for the PDP to make an access decision. Some PDPs might be stateful, and can retain data within themselves instead of always relying on a PIP. A PDP refers to its own state (which can be thought of as an internal PIP) or refers to the external PIP in order to make an access decision.

The AuthZEN working group’s charter is to standardize communication between all of these various components, with an initial focus on standardizing the API between the PEP and PDP.

So how do these relate to each other?

To understand the relationship between CAEP and AuthZEN, let’s put this in the broader context of modern zero-trust cloud architecture. Any modern enterprise depends on tens (maybe hundreds) of cloud services providing a range of services, including infrastructure, managed services, security, device and identity management, and end-user applications.

When a user accesses a specific resource within your cloud-based service, your service needs to determine whether or not that access should be allowed. Following the “P*P” pattern, the service will call a PDP to determine that. The PDP will in turn refer to data available locally to make the decision. All these interactions have to be local, because they are in the critical path of the application request, and the latency has to be minimal. Indeed, for each web page that the user loads, there may be hundreds of resources being accessed, each requiring their own access decisions.

The PDP needs to make instant decisions, but the locally available information may be out of date. This includes session properties such as whether the user is accessing the service from a managed device, whether the user’s session is still valid, and whether the user currently has the business need to access the requested resources. Each of these bits of information may be with a different cloud service, so fetching all of this at the time the user is trying to access the requested resources seriously affects latency and availability of your cloud service.

This is where CAEP comes in. CAEP can be used to asynchronously deliver the required information to any cloud service that needs to factor it in their access decisions. The access decisions themselves can use AuthZEN between the PEP and PDP. SSF provides a robust framework to determine who can subscribe to which information, and about which subjects. CAEP provides the information relevant to the session properties that can affect access decisions.

AuthZEN and the Shared Signals Framework

The pattern of asynchronous event delivery into stateful PDPs isn’t restricted to session signals. For example, the source of truth for users and groups is typically an Identity Provider (IdP) or a corporate directory such as Active Directory. User attributes and group membership are commonly used as data that informs authorization decisions. And indeed, many stateful PDPs will cache this information.

When users get added, or group memberships change, PDPs must be informed and refresh their state. SCIM Events represents a way to layer this capability on top of SSF.

Going further, when it comes to resource ownership and sharing, services typically keep track of this information, but must have a way of informing the PDP that the access control relationships between users/groups and resources have changed.

The AuthZEN working group plans to tackle these use-cases in the second half of 2025, and intends on using SSF as the foundation.

Further Reading: Rounding out the authorization architecture

The Continuous Security Paradigm (CSP)

This interplay of synchronous local decisions and asynchronous communication of required information is described in a bit more detail in the “Continuous Security Paradigm”, an article published by SSWG co-chairs Atul Tulshibagwale and Sean O’Dell in the IDPro blog.

Transaction Tokens (TraTs)

Applications, or cloud services themselves, may be composed of tens or hundreds of microservices. Any external invocation (such as the user requesting a specific transaction) results in a call chain that touches many of these microservices. Each microservice provides an internal API that can be called from within the application’s Virtual Private Cloud (VPC). Now, the application may obtain a decision from the PDP for an external invocation by the user, but doing so from each microservice may be overwhelming for a PDP. This is because every end-user action in the UI might result in hundreds of calls to the applications, and each call may touch multiple microservices. So if each microservice were to call the PDP, then for each user request the PDP might have to respond to thousands of queries.

On the other hand, one cannot assume that the VPC is safe from tampering, because there have been devastating breaches where attackers have lurked inside an application’s VPC, causing tremendous damage without leaving a trace. There are also insider attacks where empowered insiders can misuse their access to call internal APIs. Software supply chains may also be compromised, causing your legitimate services to inflict internal damage.

Transaction Tokens is an upcoming standard in the IETF that addresses all of these concerns and doesn’t require each microservice to call the PDP. It helps applications bind the decisions received from a PDP to a cryptographically signed ephemeral token, so that a decision issued by the PDP can be captured in a TraT and passed down to all microservices in a call chain. This ensures that the PDPs decision is not inadvertently or maliciously modified internally to misrepresent the intent of external users.

Conclusion

We’ve tried to cover many aspects of authorization in this post. There is much work to be done in every one of these areas, but the good news is that we are now maturing as a technology space, and the pattern proposed in CSP and implemented using standards like Shared Signals, CAEP, AuthZEN, and TraTs can go a long way in securing zero-trust cloud architectures.

About the OpenID Foundation

The OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. Founded in 2007, we are a community of technical experts leading the creation of open identity standards that are secure, interoperable, and privacy preserving. The Foundation’s OpenID Connect standard is now used by billions of people across millions of applications. In the last five years, the Financial Grade API has become the standard of choice for Open Banking and Open Data implementations, allowing people to access and share data across entities. Today, the OpenID Foundation’s standards are the connective tissue to enable people to assert their identity and access their data at scale, the scale of the internet, enabling “networks of networks” to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.