# WG Meeting: 2025-02-11
## Agenda
- Build is broken
- Risk level change pull request
- [stream_id character set](https://github.com/openid/sharedsignals/issues/229)
- Other issues
- Open PRs

## Attendees
- Atul Tulshibagwale (SGNL)
- Yair Sarig (Omnissa)
- Thomas Darimont (OIDF)
- Shayne Miel (Cisco)
- Colton Chojnacki (Beyond Identity)
- James Slocum (Beyond Identity)
- Martin Gallo (Individual)
- Tushar Raibhandare (Google)
- Brian Soby (AppOmni)
- Apoorva Deshpande (Okta)

## Notes
### Build is broken
- Ruby is not found - possibly removed from GitHub

### Risk level change pull request
- New pull request merged

### Stream_id character set
- Atul marked it as v1Final
- (Shayne) we should mention that it is "recommended" to preserve backward compatibility

### Other issues
- Tushar still working on [stream ttl pull request](https://github.com/openid/sharedsignals/pull/222)

### Open PRs
- [events_supported in metadata](https://github.com/openid/sharedsignals/issues/224)
- (Yair) Is there an obligation / commitment that you are going to allow the event to a receiver?
- (Apoorva) Should we provide a precedence order to 'events_supported' in the metadata versus the 'events_supported' in the stream configuration
- (James) In a headless way, a receiver has no way to know what events are available to them before creating the stream
- (Apoorva) Should we deprecate the `events_supported` in the response to the stream configuration calls?
- (Atul) Too drastic?
- (Shayne) It's OK to do it since we are not putting a timeline
- (Apoorva) Should we say 'not recommended for new implementations' instead?
- (Shayne) Should we say "should not" instead of "not recommended", we have used that language in the backwards compatibility section
- (Thomas) `events_supported` in metadata will leak implementations to other implementers.
- (James) We might be conflating two use cases, because by the time a receiver has the stream, they already know which events they want.
- (Apoorva) Making it headless was not the aim. We have said that discovery is a shakehand between two consenting parties.
- (Atul) There could be events that a transmitter supports which are not in the `events_supported` list in the metadata
- (Thomas) This will work
- (Apoorva) So this is still not headless
- (Atul) For some use cases it is headless, for those not mentioned in the `events_supported`, it is not.
- (Shayne) We need to call out that in the spec.
- (Apoorva) So are we saying that the stream configuration response will have all events supported?
- (James) yes, we should say that
- (Shayne) The spec says that `events_delivered` is a subset of `events_supported` and `events_requested`, but those two are optional
- (Tushar) What is the use case for having `events_supported` outside the stream if not all event types are there?
- (James) It's to be agnostic to the implementer, so a transmitter can advertise which events it supports
- (Shayne) more optionality is more incompatibility
- (James) Good point about the subset of optional fields being nonsensical
- (Yair) If the metadata is a singular endpoint for the whole transmitter, it might be valuable, but otherwise it is not

- (Atul) What will break if we don't add this capability
- (James) It prevents receivers from discovering transmitter capabilities
- (Yair) If we want this to be viable, then we need more than just events_supported.
- (Apoorva) Yes, e.g. authn and authz
- (James) Many things have been left out of this spec, authn/authz, but there are ways one can design a transmitter to do that outside the spec
- (Shayne) It is designed for existing business cases. People are implementing around current business cases. This change would be adding a "made up" business case
- (James) If we use existing business cases as the model, then is the "tail wagging the doc"
- (Atul) We could start with new use cases and see what we need to achieve that
- (Tushar) Even in the headless case, the receiver knows all the event types it supports, and the Tx can just respond with the ones it supports.
- (Atul) Should we defer to after v1Final?
- (Apoorva, Yair, Tushar) yes

- (Thomas) What is the expected behavior of a transmitter when the receiver specifies `events_requested` types that does not include any that the transmitter supports
- (Yair) `events_delivered` will be empty in that case in the resulting stream
- (Shayne) The receiver can still update the stream configuration and add the events it wants
- (Thomas) This works, perhaps this should be explicitly listed in the spec, it might work better than adding it in the metadata
- (Brian) I'd rather have an endpoint where this can be discovered.

## Action Items
- (James) to update the `events_supported` PR to
- add the deprecation language to the `events_supported` field in the stream configuration response.
- note that transmitters may support more events than those mentioned in `events_supported`