Authors / Shared Signals Co-Chairs: Atul Tulshibagwale, SGNL; Shayne Miel, Cisco; Sean O’Dell, Disney; and Tim Cappalli, Okta

The OpenID SSWG has released three new drafts for review by the OpenID Foundation membership. We would like to describe the salient features of these drafts here. At the end of the 45-day review period, members can vote on adopting these drafts as implementer’s drafts.

Shared Signals Framework - Draft 03

After the Shared Signals Framework Implementer’s Draft 02 was released, the OpenID Foundation contracted with the University of Stuttgart for performing a formal security review of the draft specification. The good news is that the findings from the preliminary report were minor, but the bad news is that addressing them required changes to the normative language in the draft. As a result, the SSWG decided to create a Draft 03, which would need to go through the OpenID review process in order to be adopted as a successor Implementer’s Draft. Because we had to do this change, we decided to update some other aspects of the framework, which are backwards compatible (i.e., anything that implements draft 02 will still be draft 03 compliant). The salient features added in this draft and the issues fixed in this draft are listed below:

Security issues addressed

• Issuer Mix Up: Draft-02 did not specify that a receiver must validate the issuer value in incoming events and API responses from the transmitter. This language has now been updated to specify that receivers must validate the iss value in events and API responses they receive from a transmitter.
• Stream Audience Mix Up and Attacker Stream Subject Insertion: Draft-02 did not specify that a transmitter must authenticate a receiver, which we have remedied in draft-03. The new language in draft-03 also requires that transmitters use TLS and recommends that receivers verify the trusted source of the transmitter URL and use HTTPS.

New features added

• Use of txn claim: Draft-03 now clarifies how to use the JWT txn claim in order to prevent cascading cyclic chains of SSF events caused by the same underlying event. By verifying that the txn claim in a newly received SSF event is the same as a previously received SSF event, the receiver can ignore subsequent events it receives. The txn claim can also be used for reconciliation or auditing purposes between a transmitter and receiver as part of “closing the loop” on security events and actions.
• SSF transmitters can now specify in their metadata whether streams they create have no subjects in them, or “all appropriate subjects” automatically added in them, immediately after the stream has been created.

Clarifications and Bug fixes

A number of minor bugs, mostly involving non-normative language such as examples, have been fixed in this draft. Some new examples have been added and existing examples have been updated to match formats that have changed since those examples were first introduced.

CAEP Draft 03

The Continuous Access Evaluation Profile now has a new draft for review. The main update in this draft is the introduction of two new CAEP events: “Session Established” and “Session Presented”. These events can help in the following ways:

Session Established:

• Notify completion of a federated identity initiated SSO
• Indicate to a monitoring service that a user has established a new session with a particular application
• Optionally bind a session to a specific device or other context so that it is easier to detect session hijacking

Session Presented:

• Helps a monitoring service detect user presence at a specific application
• Helps detect impossible travel across applications
• Helps detect changes in environmental properties, such as IP-address changes.

Together these two events can help effectively monitor an organization’s cloud services for identity threats.

In addition to these new events, the draft has been updated to reflect the new formats and fields in all examples to match the latest SSF draft.

CAEP Interoperability Specification

In March 2023, the OpenID Foundation conducted an interoperability event hosted at the Gartner IAM Summit in London. The results of that interoperability event are documented as a part of this blog post. At that time, the implementers established interoperability of the actual events being exchanged. The SSWG had already begun work on an interoperability profile that would specify more than just the event formats to be supported. So now we are pleased to announce the first version of this interoperability profile, which specifies:

• Spec versions that must be supported by transmitters
• API endpoints that must be supported by transmitters
• Authorization schemes that must be supported by transmitters
• Stream control features that must be supported by transmitters
• AddSubject behavior of transmitters
• Subject formats supported by transmitters and receivers
• Signature formats supported by transmitters and receivers
• Details of OAuth options that must be supported by transmitters and receivers
• Event types that must be supported by transmitters and receivers

We invite the general public and members of the OpenID Foundation to review the specifications that are available here. Feedback may be provided by opening an issue in the Shared Signals GitHub repository.

About the OpenID Foundation