WG Meeting: 2025-04-15

# WG Meeting: 2025-04-15 ## Agenda - event_data in SSF or CAEP/RISC? - Flow control (https://github.com/openid/sharedsignals/issues/249) ## Attendees - Atul Tulshibagwale (SGNL) - Yair Sarig (Omnissa) - Stan Bounev (VeriClouds) - George Fletcher (independent) - Tushar Raibhandare (Google) - Martin Gallo (independent) - Rob Starling (Google) - Shayne Miel (Cisco) - Jen Schreiber (Workday) ## Notes ### Event Data in SSF? - Why was it put in the CAEP and RISC spec? - (Shayne) It's because there is no suitable place in the SSF spec where it could be put - (Shayne) It should be in the SSF spec so that it can be used by any spec leveraging SSF - Atul to look into adding to SSF - (Rob) where would you put this in the SSF spec? - (Atul) perhaps a new section like "4.2.3"? - (Rob) Two event types might define the same field as something different. - (Rob) There may be reserved names that are in the SSF spec. - (Rob) We are then specifying that an event must be extensible over the base event. - (Rob) What is the contract relationship between the event descriptions in the CAEP/RISC/SCIMEvents specs over the SSF spec. - (George) If we needed, we could create a registry, but because the spec is not final, defining an optional claim for event data in SSF is probably not going to step on anyone's toes. You could look at the SSF event as being an abstract class. - (Rob) So is the intent for the SSF event description to be a superclass. - (Rob) If we think the former is fine, then we should document that - (George) So the question is whether a sub-spec should be able to transmit something that can transmit a "non-SSF" event? - (Jen) What do we mean by an SSF event? - (Rob) Does this group have control over the CAEP/RISC/SCIM events? - (all) not SCIM - (George) We could add language to the SSF spec to say that our "events" claim profiles the events claim in the SET spec. - (Shayne) Do we want to put "event_data" inside the "events" claim? - (Shayne) Another option that was proposed was that there could be separate field in the SET called "events_data", and each key in that field could be the unique key from the "events" field. - (Shayne) What about having to put OCSF events? - (Jen) Some enterprises already use custom events - (George) The other mechanism would be to reserve a claim name (e.g. "event_data") within the scope of the SETs. We could register it in the SET IANA registry. - (Rob) We talked about two alternatives - define the "event_data" within the events claim, another is to have an alternative "events_data" claim that has event data about all events. - (George) We could say that "when you are defining new events, then you must use "event_data" field to put additional fields" - (Rob) We could just give a concrete example of how to use "event_data" - (Yair) An event is that in the "device_compliance_change" event, one might want to include some details about how the device is non-compliant. - (Tushar) Couldn't you use "reason_admin", "reason_user" for that purpose? - (Jen/Shayne) That was overloading those fields - (Jen) We should just evaluate the specific event type definition to say whether we need additional fields - (Shayne) If there is some data that needs to be added, we could just add those as additional fields in the event. Receivers can ignore it unless they can deal with it. - (Atul) Should we punt on this right now? - (Tushar) They could subclass the event and specify it for their receivers. The URI that specifies the event would change in that case - (Yair) If you change the URI, then you are making it incompatible to receivers who expect the standard event. - (Tushar) The only thing is that it loses the structure. - (George) It's fine to do this within an enterprise, but when you have a SaaS product that wants to rely on the additional data, then we might need more agreement than within one enterprise. - (George) The risk in not specifying this is that you get mutually conflicting fields, but we might not need to solve it right now (for 1.0) - (Atul) Should we punt on this issue for v1Final? - (George) Non-normative text about being able to add custom fields could be useful - (George) Specs like OAuth have such language, which say that if you don't understand those fields, you should ignore them. This is better than the spec being silent, which could lead to different implementations. I've seen this happen where people use very hard-coded / rigid parsers, so having non-normative text will help. - (George) This could be tested in interoperability tests too. - (Rob) I'd support having more structure, including saying that receivers should ignore fields they don't understand. - (Atul) Let's go with the minimum that we agree on, which is that receivers should ignore event fields they don't understand. ### Flow Control - (Tushar) Right now there is no language about how long a transmitter stores the data if it fails to deliver events to the receiver. Example situations - receiver down (push), paused stream, receiver not pulling frequently enough (pull) - (Tushar) Another aspect is that there may be busy times for a Transmitter, but there is no way for a receiver to express how much traffic it can handle - (Yair) Added two links to previous issues that we discussed that are related to this - (Yair) I don't know how much metadata we should be adding. Can we instead have error codes with an expected backoff behavior - (Yair) there are standard http status codes for that (429) - (Yair) agree about the first point, because otherwise the Transmitter might be expected to keep the data forever - (George) If you are starting to get backed up, then is there a priority of events that you want to receive? Can you create multiple streams with different priorities? - (George) There might be some events that you don't want to use and others that are less critical and possibly ok to lose. - (George) If we are adding flow control, then we should have some way of specifying this. - (Atul) We could add language that specifies creating different streams for different priority events - (Yair) Transmitters can end up accumulating events in multiple situations, so we need to add language about what the transmitter can do. - (Atul) We should add language to the spec to add a per-stream limit of how much data / how many events / time period a Transmitter can hold, and add some language that recommends the use of multiple streams for different priorities - (Shayne) Who decides the priority of events? - (George) The receiver needs to make a determination which events are important to it and it doesn't want to drop. So if a receiever gets overloaded, then it can drop the low-pri stream. ## Action Items