# 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.