[Openid-specs-risc] Call notes

Atul Tulshibagwale atul.tulshibagwale at crowdstrike.com
Tue Aug 11 19:11:09 UTC 2026 

Hi all,
The notes from today's meeting are stored here
<https://github.com/openid/sharedsignals/wiki/WG-Meeting:-2026%E2%80%9008-11>
and copied below.

Thanks to those who participated,
Atul

---
WG Meeting: 2026-08-11 <#Agenda>Agenda

   - Poll based receivers
   - Mike's versioning PR (#310
   <https://github.com/openid/sharedsignals/pull/310>)
   - Yair's PR: device management state change (#329
   <https://github.com/openid/sharedsignals/pull/329>)
   - Thomas: Additional CAEP Events for CAEP Interop
   - WISE: Instances in subjects

<#Attendees>Attendees

   - Yair Sarig (Omnissa)
   - Atul Tulshibagwale (CrowdStrike)
   - Apoorva Deshpande (Okta)
   - Mike Kiser (SailPoint)
   - Sahil Mukhija (CVS Health)
   - John Marchesini (Jamf)
   - Debayan Basu (Independent)
   - Thomas Darimont (OIDF)
   - Martin Gallo (Independent)
   - Jack Zaldivar (Databricks)

<#Notes>Notes <#Poll-receivers>Poll receivers

   - We're short by 2 receivers that use poll delivery in order to launch
   the certification program.
   - (Sahil) We will be able to test by end of September

<#Versioning-PR>Versioning PR

   - (Mike) Do we need to have the old copies?
      - (Apoorva) What do you mean not keep them? We need the published
      copies.
      - (Mike) Joseph suggested to keep the old copies if we need to make
      changes
      - (Mike) FAPI and others have kept the old files in order to work on
      errata
      - (atul) we should probably link to it from our spec page . . .
      - (apporva) we use to link copies under drafts, but we haven't done
      that recently
      - (atul) Should the change from Yair's PR that changes the base URL
      of the events go into Mike's PR?
         - (Yair) yes.
      - (Thomas) We should look at how OID4VC folks did it (for the VCI
      spec). They have copied the 1.0 file to the 1.1 file to retain the GitHub
      history, and then moved the 1.1 file to a "1.1" folder.

<#Device-compliance-change-PR>Device compliance change PR

   - (Yair) I'll work on a new PR, once Mike has merged his.

<#Additional-Events-in-Interop>Additional Events in Interop

   - (Thomas) A vendor wanted to try out the conformance suite, and they
   only support the "risk level change" event, and no other event. So they
   cannot use the tests as they stand right now - because the test suite
   requires at least one of "session revoked", "credentials change", or
   "device compliance change".
   - (Thomas) We should be able to support this, so should we allow this
   event as one of the events?
   - (Apoorva) We should drop the requirement for the events, and allow any
   events from the CAEP spec. We could include other specs later.
   - (Atul) In the future we may have implementers implementing just some
   CAEP or RISC or SCIM events.
   - (Thomas) I could support all known (e.g. CAEP) events. It's fine to
   limit it to CAEP for now, and later introduce other event types.
   - (Thomas) The main purpose is to demo interoperability at the protocol
   level. For that, it is sufficient to process at least one of the CAEP
   events. If the transmitter and receiver don't have an overlapping set of
   events, then we will have a problem.
   - (Apoorva) Originally, I had brought this up. Interop should be about
   the plumbing. But if we drop this requirement now, what happens to the
   60-day period.
   - (Yair) Are we going to list the events that an implementation is
   certified for.
      - (Thomas) No. We're not listing event types. Its just that the
      conformance test suite claims to only know about the session revoked,
      credentials change, and device copmliance change events.
      - (Thomas) But we don't specify in the certification which events are
      supported by this implementation
   - (Apoorva) The spec currently requires one of 3 events: session
   revoked, credential change, or device compliance change.
   - (Yair) If we need to change the spec, we should also take care of the
   complex subject issue. (We should allow complex subjects that include the
   three formats: email, iss-sub, and opaque - only for verification)
   - (Thomas) See: CAEP Interop Profile Suggestions
   - (George) What is the goal for people to be certified. There seems to
   be a lot of variability in what it means to be certified, for example,
   implementation 1 supports 2 events, and the other support the 3rd event,
   then it is still incompatible. Can you have certification to mean "I
   implemented SSF correctly". When events get added, the permutations
   explode. Does certification mean interoperability, or does it mean
   something else.
   - (Thomas) Certification is currently specified as such. We had
   use-cases only as a "lowest common denominator" thing. We don't really care
   about what an implementation does with the event it sends or receives.
   - (Thomas) The fact that we are just limited to those 3 event types is
   an arbitrary decision, based on the most common implementations we were
   seeing.
   - (George) IIUC, the goal is that "I implement SSF correctly", and the
   way to do it is by showing that I support specific event types. Today, the
   test framework supports 3 known events, but we can extend that to mean any
   CAEP event. I think that is useful (that you implemented th core protocol
   correctly).
   - (Thomas) Yes, that is as it is intended right now. The CAEP Interop
   Profile gives us a framework that specifies the required capabilities. The
   number / type of events supported is actually a 2nd order thing.
   - (George) I don't think the interop and certification have to be the
   same. If the certification isn't going to say "you have implemented these
   events correctly", then the certification is not the same as the interop
   profile.
   - (Atul) How about we keep the interop profile unchanged, but we loosen
   the requirement in the certification tests to be any CAEP Event, not just
   the three.
   - (Thomas) We should align with the spec wording. I would recommend to
   change the spec to loosen the requirement. See my suggested text below.
   - (Yair) Should we also add complex subjects in that PR then?
   - (Thomas) Supporting complex subject type is very common.
   - (Yair) If I send a "device compliance" event with a complex subject,
   then will it pass certificaiton?
      - (Thomas) Not at this time.
   - (Yair) The suggestion is to add complex as one of the types that must
   be supported, and it can include two or more members that are already
   specified (email, iss-sub, and opaque).

<#Action-Items>Action Items

   - Atul to create a PR to loosen this requirement, considering Thomas'
   language suggestion below. We can then discuss that PR in the next meeting.
   -

<#Misc>Misc <#Thomas-CAEP-Interop-Profile-Suggestions>Thomas' CAEP Interop
Profile Suggestions

Change section 3. to ## 3. Event Types and Use Cases

## 3. Event Types and Use Cases

### 3.1. General Requirements

An implementation conforming to this profile MUST support at least one CAEP
[CAEP] event type, and MUST declare each event type it supports.

For each declared event type:

-  A Transmitter MUST be able to generate events of that type as defined in
   [CAEP], MUST populate all claims defined as REQUIRED for that type, and
   MUST populate `reason_admin` with a non-empty object.

-  A Receiver MUST be able to accept events of that type and MUST interpret
   all claims defined as REQUIRED for that type in [CAEP]. A Receiver MUST
   NOT reject an event solely because it contains OPTIONAL claims that the
   Receiver does not interpret.

Sections 3.2 through 3.n define additional requirements for specific event
types. An implementation declaring support for an event type profiled in
those sections MUST also meet the requirements of the corresponding
subsection.

Add a Risk Level Change use-case

### 3.4. Risk Level Change

In order to support notifying and responding to changes in the assessed
risk level of a subject, implementations MUST support the CAEP event type
`risk-level-change`. This event is used to signal that the Transmitter's
assessment of the risk associated with a subject has changed.
Implementations MUST support the following field values:

`principal`
Receivers MUST interpret all allowable values of this field. Transmitters
MAY generate any allowable value of this field

`current_level`
Receivers MUST interpret all allowable values of this field. Transmitters
MAY generate any allowable value of this field

`previous_level`
Receivers MUST interpret all allowable values of this field, and MUST
handle its absence as specified in [CAEP]. Transmitters SHOULD populate
this field when the previous risk level is known to the Transmitter

`reason_admin`
Transmitters MUST populate this value with a non-empty object
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260811/52a8fd05/attachment-0001.htm>

More information about the Openid-specs-risc mailing list