WG Meeting: 2025-05-13

# WG Meeting: 2025-05-13 ## Agenda - Postpone [addressing limits issue](https://github.com/openid/sharedsignals/issues/249)? - Where to host event profiles ## Attendees - Atul Tulshibagwale (SGNL) - Shayne Miel (Cisco) - Yair Sarig (Omnissa) - Thomas Darimont (OIDF) - Sam Weiss (Jamf) - John Marchesini (Jamf) - Tushar Raibhandare (Google) - Apoorva Deshpande (Okta) - Alan Pinkert (Cisco) ## Notes ### John Marchesini introduction - Jamf ### Robert Gallagher introduction - Mastercard - Active on FAPI group - Interested in a few other WGs ### Vladimir Slesarev - Cyberark ### Flow control / limits issue: - [link](https://github.com/openid/sharedsignals/issues/249) - (Tushar) There are two aspects: Receiver and Transmitter - The status code 429 addresses the receiver side - The Transmitter side - I agree that we can postpone because of the unanswered questions - (Apoorva) Not clear why we should bring this in to v1. - (Yair) It was raised even before because the way the language is right now, we imply that the transmitter is supposed to retain all messages. So it is confusing right now. - One option is to change the language that the transmitter can drop events if required. - The language right now says "SHOULD", which makes it unclear as to until when it should. - Are we doing any testing about this in the interoperability / conformance tests? - (Shayne) I agree the language is confusing. The use of the word "will" in the paused state (8.1.2.1) is confusing. - (Apoorva) Same with disabled state - (Yair) So it is confusing to a transmitter developer because the transmitter doesn't know what to do if it cannot. - (Apoorva) The following sentences talk about the time duration. - (Thomas - in chat) The conformance testing currently tests supported stream state changes, but not event persistence. - (Atul) It doesn't appear to be stopping people from implementing the spec. - (Yair) People aren't implementing because of this issue. - (Tushar) can we soften the language? Would it solve the immediate concern? - (Yair) I believe so. The language implies that the transmitter needs to make an effort to keep all events - (Tushar) Can we add a sentence that the Transmitter can determine how much and how long to retain events. - (Yair) That will help - (Vladimir) Can we soften the language to "MAY" instead of "SHOULD" - (Shayne) We can put the "MAY" in the follow up sentence. I.e. The Transmitter MAY drop events if it exceeds time or data limits. - (Yair) Agree with Shayne - (Vladimir) Yes, that seems to... - (Thomas) How does the transmitter indicate its policy? - (Shayne) We have postponed that discussion as a result of this. - (Apoorva) Does this unblock us for the last call? - (Atul) Yes, I believe so. - (Atul) It'll be great if we can send the final draft for OIDF review before Identiverse ### Event profiles - (Shayne) I mean profiles like CAEP, RISC and SCIM events - (Shayne) This is coming up because Alan and I are discussing an SSF profile for [OCSF](https://github.com/ocsf) - (Shayne) We have two models: CAEP and RISC are in OpenID, and SCIM Events are in IETF. - (Shayne) There is an existing body of work for OCSF, so what are the pros and cons of putting that profile in OCSF or OpenID - (Apoorva) Quick question: What are the events, what is the scope? - (Alan) I'm one of the OCSF maintainers - It's very cross-domain, there are a number of categories of events - There is an explorer at [schema.ocsf.io](https://schema.ocsf.io) - It's not just raw telemetry, but also enriched events for finding data, remediations, analyses, etc. - Vendor agnostic schema for security events - It came to mind because Cisco is working on both, and we were wonding if it makes sense to combine and leverage SSF - (Shayne) OCSF has event schemas, but doesn't define protocol or format - (Alan) Correct, there are JSON and protobuf encodings of schemas. - (Shayne) From a use-case point of view, we have seen it been used in SIEMs - (Alan) We have seen adoptions in either natively producing or translating to OCSF. E.g. AWS security lake, a few AI startups, and a couple of folks mention that customers are asking about it. We're seeing more activity on the consuming side - (Yair) Is there any concern about the subject format / how it is described in SSF? Is it compatible with SSF? - (Alan) I haven't done a deep dive and we would like to hammer it out. - (Alan) There are definitely a lot of events where the subject format won't be an issue. - (Alan) There are many, many events in OCSF. If we had a way to generalize the creation of events in SSF, we could even add it to the OCSF documentation. - (Yair) A typical question of ownership might come up. When OCSF evolves, who is responsible to maintain the profile. If it belongs in OCSF, and they can evolve it, then the work can be done in OCSF. If it needs to evolve separately, then it can be done in OIDF. - (Atul) Great point. - (Shayne) What if we have a profile in OCSF that specifies how to wrap OCSF events in SSF, and there is a way to find OCSF support from the shared signals working group. Right now there is no way to know that SCIM events can use SSF by looking at the OIDF resources - (Apoorva) One question: Is there overlap with STIX and TAXII? - We have heard multiple times about OCSF - (Alan) In OCSF working group we have talked about other frameworks. There is some participation from the STIX and TAXII folks. There is also some discussion about the MITRE ATT&CK framework. I can follow up with you if interested - (Alan - in chat) how does OCSF relate to STIX and other security schemas: https://github.com/ocsf/ocsf-docs/tree/main/FAQs#how-does-ocsf-relate-to-stix ## Action Items - Yair to create PR to add the language discussed above - Atul to issue last call after Yair's PR is merged. - Shayne and Alan to post to the mailing list to build awareness and get suggestions about how this work can proceed