WG‐Meeting‐2026‐03 17 - openid/sharedsignals GitHub Wiki
Agenda
How to report "user disabled" using CAEP
Checking in on activities:
Certification tests
Action Receipts
On-demand status updates
WIMSE Events
Microsoft and Shared Signals :)
Attendees
Atul Tulshibagwale (CrowdStrike)
Yair Sarig (Omnissa)
Mike Kiser (SailPoint)
John Marchesini (Jamf)
Jen schreiber (Crowdstrike)
Thomas Darimont (OIDF)
Sean O'Dell (CVS)
Apoorva Deshpande (Okta)
Notes
User Disabled
(Yair) In CAEP we have a "credential change", but that doesn't address the "user disabled" case
(Yair) There is a RISC event named "account disabled", but that is not exactly what I'm looking for.
(Atul) How is "user disabled" different from "account disabled"?
(Yair) Many receivers might only be listening for CAEP events, and not RISC events.
(Yair) If we have "credentials change", why don't we have "user disabled"
(Mike) I think there's a semantic difference: Account disabled is about a specific account on the system. I can see how "user disabled" is different, in that you want to nuke everything, including sessions. It's more of an "identity disabled" rather than an "account disabled" event.
(Atul) Wouldn't a receiver receiving a RISC account disabled event take all the session actions too?
(Yair) A user may have multiple accounts.
(Atul) Wouldn't that be addressed by the "subject" field?
(Sean) In a complex environment, a simple subject won't work. Say a user has 4 different accounts in AD, Entra and LDAP. The "alias" subject could specify all of the accounts. From an identity perspective, a delete is disastrous, but a "disabled" can work.
(Sean) So the "account disabled" event could work. This is why SCIM Events are key here. You could even do this without RISC events. You could just do a SCIM Deactivate.
(Yair) Apple only listens to CAEP, for example.
(Sean) If you are, say, honeypotting a bad actor. You could disable one specific account and see how they react.
(Atul) How comprehensive should a set of events be and the use cases they address.
(Atul) If it affects teh session == CAPE, acct mgmt == SCIM, accounts / account security == RISC
(Yair) We have cred change in CAEP, but not "user disabled". Feels like we landed halfway in the middle
(Yair) They talk more about CAEP vs Signals or Shared Signals.
(Sean) This goes back to the conformance testing conversation. Why only CAEP for that? You can't discriminate between CAEP / RISC / SCIM Events. If you are typically support one, you should support the others. The grand schema should be "Shared Signals"
(Atul) Cred Change might be softer than a session revoke and not inconvenience a user.
(Yair) if the user is disabled then what are they going to do? The receiver might be able to decide what to do to cause the revocation. How you react to the session revoked versus disablement might be different.
(Atul) Should cred-change be moved to RISC?
(Yair) CAEP is just CAEP...be clear on communication of events and event type.
(Atul) History matters and CAEP>SSF but not SSF is more mainstream.
(Atul) Maybe we jsut acknowledge we are stuck with cred change where it is in CAEP.
(Yair) We could add the reason in session revoked (i.e. like cred change aka admin reason)
(Apoorva) An account could have multiple credentials, so a credential change with a "disabled" status won't work the same as "account disabled".
(Sean) adding in admin
(Atul) We could just acknowledge that "credential change" should ideally belong in RISC, but future events that relate to accounts should go into RISC.
(Sean and Atul) Ideally we should care about the use cases and not profiles.
(Sean) WIMSE is looking to create supply chain related SSF events
(Jen) Brought up this was talked about a while ago about profiling SET events or shared signals or just adding events? CAEP interop vs SSF Interop...her and Atul are arguing about stuff (joking - haha!).
(Atul) CAEP and RISC can introduce other aspect with regards to SSF Events and has crossover in interop profiles.
(Atul) Pushing Google on getting RISC introduced.
Certification Update
(Thomas) I picked up the work, but got distracted again. I will need to pick it up again later. Some folks tried the tests and we got some feedback. I'm incorporating the feedback.
Action Receipts
(Sean) Repo has been forked and getting a baseline in place and will blast the mailing list
(Sean) Kiser and I talked and are incorporating separate pieces so then we can track it with comments.
On-demand status updates
(Yair) We need a way to get an initial status of some property / point in time. Not working on it now so we an table it for another time.
(Sean) office hours help here?
(Yair) A lot of customer need it for certifiaction and cant tolerate the latency and want point of time. If we expose an api in the response to tell them what is in it and async is added there are issues.
(Sean) You wanted the state of a device at a point in time, right? (Yair) Yes
(Yair) It's very useful to have this ability, but I'm trying to articulate the use case.
(Atul) use case - a Rx goes down and when it comes back up, it might want to know what events transpired?
(Yair) use case - if the Tx disabled the stream then we have event loss.
(Sean) now we are mixing operating a streaming service with shared signals in a working group
(Atul) If a cache goes down that has JWT tokens, can we answer the question of "who was revoked"? The cache is consulted but if the Tx cant update the cache...there is a gap.
(Yair) What we really want is to know the state of the JWT right now.
(Thomas) MQTT use case wehre the broker would buffer events for a "receiver" if the receiver isn't online. A capability to declare ifa s tream should use a "persistent session" would help to handle that.
(Yair) Are we saying for how long we are keeping the events and replay them?
(Thomas) Delivery and messaging of time and the "what" is what can be used to control buffer and/or behavior.
(Atul) This is a poor fit for the event setup (i.e. the "current state"). This is why you have SCIM Events versus SCIM API's. There is work going on now to fit devices into the SCIM Schema.
Microsoft and Shared Signals
(Sean) There's benefits of being in a Fortune 5 co. I got introduced to their Product Owner / Engg Executive, they will be supporting SSF in their ITDR platform.
(Sean) I gave the use case that if an agent / user needs to be able to read messages, there should be a standardized way of removing that.
(Sean) Discussing this with Microsoft at RSAC next week.
(Sean) The other use case was to be able to revoke Entra sessions, without calling the Graph API, and they agreed that SSF is the way.
(Thomas) Does this mean that Microsoft will act as an SSF Receiver
(Sean) Yes, there may be a particular level of license that you require for this.
(Sean) They're starting to understand the interoperability required. They got the message when Sean pointed out that a number of other large players are doing it.
(Sean) They will talk about it when they have a harder timeline.