Instant Transmitter Recipe
Use the caep.dev Transmitter in 4 Simple Steps:
Step 1 Register and get an access token
Step 2 Create a Stream using the Postman Collection
- Insert the Access Token you downloaded in the registration process in the Authorization header as “Bearer <access token value>”
- Execute the “Create Stream” method in the Postman Collection. You are now ready to receive events
Step 3 Generate an event from caep.dev
Step 4 Receive the event in your Receiver using the Postman Collection
- Insert the Access Token you downloaded in the registration process as the value of the Authorization header as “Bearer <access token value>”
- Execute the “Poll” method to check for events
Note Acknowledge the event:
- Once you have received an event, you must acknowledge its "jti" value in the next poll request so that it is not delivered again. If you do not acknowledge a previously received event, it will be resent after a short timeout (~5 minutes). See RFC 8936 for details
Instant Receiver Recipe
You can quickly see how the caep.dev Receiver works by testing it against the caep.dev Transmitter! Follow the steps below:
Step 1 Register and get an access token
Step 2 Create a Stream
- Insert the Access Token you downloaded in the registration process in the Receiver screen
- Create a Stream: To use it with the caep.dev Transmitter, you can use the same access token that you downloaded when you registered with caep.dev. The Transmitter Configuration Metadata URL is
https://ssf.caep.dev/.well-known/ssf-configuration. The audience value that you provide here must be the same as the audience value that you provided when you registered for caep.dev. This value is pre-populated in the form.
Step 3 Transmit an Event: Use your Transmitter to send an event to your Receiver. Make sure the event type is one that you requested when creating the stream
Step 4 Wait for the poll interval (if you set up the stream as a poll-based stream), then see the received event:
Receive CAEP Events
If you do not have an existing CAEP receiver, here’s a simple way to get started. Download the “Postman Collection” for use with the Postman tool. With this Postman Collection you can:
- Use the Access Token you download in the registration process
- Create a Stream with the caep.dev Transmitter
- Poll for events from the caep.dev Transmitter
Open-Source Go Lang Receiver
You can get a jump start on your Shared Signals Receiver implementation by using the caep.dev open source receiver. Click here to go to the GitHub repository.
CAEP FAQ
What are “Shared Signals”, CAEP and RISC and how do they relate to each other?
The Shared Signals Framework (SSF) is the specification that defines how independent entities can establish a publish and subscribe relationship between themselves to exchange events of mutual interest. It specifies how the events are formatted, describes the subjects within those events, how they may be delivered and how the streams of events are managed.
The Continuous Access Evaluation Profile (CAEP) is a specification that applies SSF to the area of access management. It specifies events that need to be exchanged between parties that share user sessions. This can include Identity Providers (IdPs) and Service Providers (SPs) in a federated identity network, or device management or endpoint security services and applications.
The Risk Incident Sharing and Coordination (RISC) profile is a specification that applies SSF to the area of account management. It specifies events that need to be exchanged between parties that share user accounts.
Shared Signals is the name of the working group in the OpenID Foundation where all these specifications are being developed.
Who can be a Transmitter? Who can be a Receiver?
Any network service that can be trusted to asynchronously provide information of interest to other network services can be a Transmitter. Similarly, any network service that can trust other network services to asynchronously provide it information can be a Receiver.
For example, in a federated identity network, an Identity Provider (IdP) may be a SSF Transmitter for events such as “session revocation”, where the Service Provider (SP) is a SSF Receiver. The SP may be a SSF Transmitter for events such as “Assurance Level Changed”, where the IdP can be a SSF Receiver.
Can a service be a Transmitter and Receiver at the same time?
A network service can be a Transmitter to some services and a Receiver to some services at the same time. It can be a Transmitter and a Receiver to the same peer service.
Does SSF require individual events to be signed?
SSF events are “Security Event Tokens” (SETs), which in turn are “JSON Web Tokens” (JWTs). SSF events are not required to be signed by any of these specifications as long as the communication mechanism has integrity protection built into it. Transport Layer Security (TLS), the most common way of communicating SSF events, has such integrity protection. However, the events need to be signed if a component within the Receiver needs to independently verify the authenticity of the SSF event without relying on the transport layer.
Graphical Overview of the Shared Signals Framework
The Shared Signals Framework is an open standard for webhooks, a means of notifying interested parties asynchronously about events of interest. It enables Receivers of events to discover Transmitter capabilities, for both parties to manage streams of specific event types between the Transmitter and Receiver and for both parties to add or remove subjects from the streams about which the events are communicated. It has a flexible framework for defining subjects from being very specific (session x of user with email y on device z).
CAEP Events
The following event types are defined by the CAEP specification. CAEP follows a "descriptive" style, in that it does not prescribe any action on the receiver of the events. The event types and their descriptions are given below.
| Name | Description |
|---|---|
| Session Revoked | Transmitter has revoked the session |
| Token Claims Change | Transmitter has provided new values for claims for tokens previously sent |
| Credential Change | Transmitter has new credential for the subject |
| Assurance Level Change | Transmitter has a new assurance level for the subject |
| Device Compliance Change | Transmitter has determined a new compliance value for the subject |
