# WG Meeting: 2023-04-04 ## Agenda - https://github.com/openid/sharedsignals/issues/19 - https://github.com/openid/sharedsignals/issues/39 - https://github.com/openid/sharedsignals/issues/36 - https://github.com/openid/sharedsignals/issues/32 - caep.dev demo, sponsorship and support - Expectations between a Transmitter and a Reciever (does the Transmitter need to support different set of events depending upon a Receiver) ## Attendees - Atul Tulshibagwale (SGNL) - Shayne Miel (Cisco) - Eric Karlinsky (Okta) - Shrinivas Challa (Workday) - Greg Brown (Axiad) - Debora Comparin (Thales) - Phil Hunt - Tim Cappalli (Microsoft) - Frank Taylor (VMWare) - Nancy Cam Winget (Cisco) ## Notes ### caep.dev - SGNL is sponsoring caep.dev today—open to more sponsors. - caep.dev is a SSF transmitter. - Will be live on Tuesday April 11 Feedback: - This is awesome! - Suggestion is to make it more clear that CAEP is an event profile and SSF is the transmission framework. Q: What does it mean to be a sponsor? - Supports the development. Roadmap: Open Source receiver tooling. - Ask: Provide feedback. Q: Should we focus so heavily on CAEP, versus SSF generally? - Shayne Miel - +1 Eric Karlinsky - +1 Tim Cappalli - We are already fighting confusion about what CAEP is.. CAEP is a list of events, that's it. Perhaps we should "brand" this site as an SSF transmitter. - Phil Hunt - A general purpose SSF site would be preferred, as something that OpenID Foundation would back. No objections raised to OIDF supporting the launch of this website via a press release, e.g.. ### Transmitter / Receiver expectations on "events_supported" - A Transmitter may put different events_supported in each stream configuration it creates with even the same Receiver (or different Receivers) - events_supported was supposed to be describing what events the Transmitter is technically capable of supporting - events_delivered is supposed to describe what the stream can contain - Q: (Eric) Is events_delivered just an intersection of events_supported and events_requested? - A: What features may determine which events are delivered? It could be the license of the Receiver, based on an authorization - The stream configuration endpoint appears like a static endpoint in the metadata. Would there be a separate URL for each stream configuration in that case? - The response will be dependent on the token, not necessarily the URL - It will help to clarify in the spec that the output of "events_delivered" is within the purview of the Transmitter based on the business relationship between the Receiver and Transmitter - There seems to be a conflict between "self discovery" (what was intended a few years ago) and the need for hiding the list of events supported (for security reasons) - How do you discover new event types supported by the Transmitter without having to supply an authorization token? - Is automation the only driver there? An admin could need to see this in a UI for planning / policy definition purposes - How would the Receiver know what is possible versus what is available to it? - Is the discovery "offline" / out of band? How much discovery is worth having in the protocol? - In a SSF Gateway for example, the list of supported events may depend on the tenant that the requests are being routed to. - Leaving the language neutral (as it is now) makes both possible - The present spec specifies "events_delivered" as the intersection of "events_supported" and "events_requested", but the spec should clarify that it may not have everything from the intersection - What happens when a Transmitter dynamically is able to support a different set of events from what was shared earlier? - Receivers must poll the Transmitter (using Get Stream Configuration) to find out new events that become available - Should we clarify that "events_supported" may be a subset of everything the Transmitter technically is capable of supporting? Yes (some on the call agreed) ## Action Items - Create an issue to: Clarify "events_delivered" is not necessarily the entire intersection of "events_supported" and "events_requested" - Create an issue to: Add text to clarify that "events_supported" may not always be everything that the Transmitter is technically capable of supporting.