# WG Meeting: 2023-09-19
## Agenda
- [Issue 116](https://github.com/openid/sharedsignals/issues/116)
- [PR 117 Discussion on empty `events_requested`](https://github.com/openid/sharedsignals/pull/117)
- [Resolution on sub_id vs subject in PR #82](https://github.com/openid/sharedsignals/pull/82)
-

## Attendees
- Atul Tulshibagwale (SGNL)
- Phil Hunt (Independent ID)
- Mike Kiser (SailPoint)
- Shayne Miel (Cisco)
- Sean O'Dell (independent)
- Yair Sarig (VMWare)
- Nick Wooler (Cisco)
- Nancy Cam Winget (Cisco)
- Tim Cappalli (Microsoft)
- Edmund Jay ()

## Notes
### Updates to the Transmitter Configuration Metadata [Issue #116](https://github.com/openid/sharedsignals/issues/116)
- (Atul) Change implies we're describing a Receiver
- (Phil) Didn't want to make a breaking change, but I'd like to describe something that is both a Receiver and a Transmitter. This is why I've only proposed a new delivery method supported and not changed `transmitter_configuration`
- (Phil) I'm facing this in my SCIM server implementation. I need the server to be both a Transmitter and Receiver
- (Atul) Does this make the spec a little confusing because the spec as it stands does not provide a way to describe a Receiver. Adding Receiver details in a Transmitter Configuration Metadata may confuse readers
- (Sean) An ACK for a client and an ACK for a SCIM server is different(?)
- (Sean) Need to understand the SCIM use case better. Is the SCIM server both a SCIM server and a client?
- (Atul) While this is important, I would like to move this to post draft-02, so that people starting to implement can work on draft-02 instead of draft-01
- (Phil) We are trying to lock down a relationship by way of this protocol. If you don't set up a Receiver right now, we will have a breaking change later
- (Phil) I have to do this, and I will implement it a certain way, but
- (Shayne) The reason we have an API for Transmitters is because some other entity coming to the Transmitter to receive signals. It may not be the case the other way around
- (Phil) Is this a "push only" perspective? In the current spec the Transmitter has to start first, and then the Receiver
- (Tim) We are at risk of people not considering SSF because we are not making progress. We need to draw a line somewhere, and get a new draft out.
- (Atul) We can keep the PR open and consider it after draft-02 is proposed for vote

### [PR 117 Discussion on empty `events_requested`](https://github.com/openid/sharedsignals/pull/117)
- (Shayne) Should verification and "stream updated" events always be in streams?
- (Shayne) It should be possible for Receivers to request empty streams, because they can add event types later
- (Atul) I suggest we add language in the spec that says the verification and stream updated events are always present in the stream regardless of what the Receiver has requested
- (Phil) We have both `events_delivered` and `events_requested` So what is the meaning of passing a empty value
- (Atul) We should update the language in the PR to say something like: `events_requested` SHOULD NOT be empty. If no changes are to be asserted in a stream update, this field MUST NOT be included.

### [Resolution on sub_id vs subject in PR #82](https://github.com/openid/sharedsignals/pull/82)
- (Atul) Trying to resolve Apoorva's comment that changing `subject` in the verification event is a breaking change.
- (Phil) Do we need to have a subject in a verification event?
-
## Action Items
- Atul to send out an email describing this issue (PR #82) better and soliciting comments on email, or discuss in next meeting.
-