WG Meeting: 2025-02-11

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