# WG Meeting: 2023-08-29
## Agenda
- [Transmitter's ability to update stream content](https://github.com/openid/sharedsignals/issues/103)
- [Empty `events_requested` field in Create Stream](https://github.com/openid/sharedsignals/pull/100)
- [Decoupling SSF metadata from OAuth](https://github.com/openid/sharedsignals/pull/101)
- [Conclude on `format` PR](https://github.com/openid/sharedsignals/pull/87)

## Attendees
- Atul Tulshibagwale (SGNL)
- Phillip Hunt (Independent ID)
- Steve Venema (Forgerock)
- Apoorva Deshpande (Okta)
- Yair Sarig (VMWare)
- Edumund Jay ()
- Tim Cappalli (Microsoft)

## Notes
### [Transmitter's ability to update stream content](https://github.com/openid/sharedsignals/issues/103)

- (Apoorva) I want to make sure that Transmitters have the ability to change the subjects included in the stream
- (Atul) Should the Transmitter have to tell the Receiver that it honors an Add Subject
- (Phil) That could lead to harvesting information from the Transmitter
- (Yair) If I create a new stream and don't make any add subject calls, does that mean all subjects are included are no subjects are included?
- (Phil) The initial idea was that as a part of an initial authorization request, such add subject calls are required. In other cases, e.g. SCIM, all subjects are included by default
- (Atul) I agree we don't need to put strong normative language in the semantics of the Create Stream
- (Phil) It could be a Transmitter discretion whether or not they should indicate whether an AddSubject succeeded or not
- (Yair) There may be additional fields that indicate to the Transmitter whether all subjects should be included or not
- (Phil) We could add a filter at the time of stream creation
- (Steve) There's a concrete use case for this: Our infosec would like to know about any "forgerock.com" identity for a subset of events that Google could notify us for. In our case, "forgerock.com" is not a separate tenant of Google
- (Phil) Would a Receiver want to know the total universe of subjects in the stream?
- (Apoorva / Steve) That sounds a bit like SCIM
- (Steve) The filter seems to have value
- (Phil) There are possibly two use cases:
- User centric: User needs to consent to share events. The spec is well designed for this.
- Enterprise use case: Consent belongs to the enterprise, so every account using a specific service must be included in the stream
- (Phil) Does this lead to an interop issue
- (Phil) In a typical SCIM use case all subjects are included by default. This is more of an admin issue than an interop issue
- (Apoorva) How would a transmitter limit the audience of a stream to only a certain number of users
- (Atul) Two issues here:
- What is the semantics when the stream is created
- How does the Transmitter add / remove subjects
- (Yair) Filtering may be useful in many cases
- (Phil) What if we just spec-ed that the Transmitter is always authoritative over what subjects it sends events about. The Transmitter may add or remove subjects as it desires.
- (Phil) We could leave the spec unchanged, because it can be configured administratively
- (Phil) We could leverage the SCIM filter language that is based on path. But what are you filtering against.
- (Phil) Issue with adding a filter e.g. email ends with @okta.com, what is the Transmitter comparing that against?
- (Steve) Events won't be sent if they don't match the filter specification
- (Phil) We don't want to force the Transmitter to look up a database before sending an event
- (Yair) The device use cases, the id is only a device ID, and the Transmitter may not have this information
- (Atul) Should we list this as a "known issue" in the spec?
- (Phil) agree, but we should make sure that any normative language about subject content in the stream should be avoided. This will enable us to craft a more specific solution later that doesn't break backward compatibility
- (Phil) Even SCIM is trying to define how to define the scope of each domain

### [Decoupling SSF metadata from OAuth](https://github.com/openid/sharedsignals/pull/101)

- (Atul) Value of the "scheme" field can be the URN
-

### [Empty `events_requested` field in Create / Update Stream](https://github.com/openid/sharedsignals/pull/100)

- (Apoorva) What would be the use of creating a stream with no "events_requested"
- (Phil) There's a way around this: There are three params:
- events_requested
- events_supported
- events_delivered
- (Phil) If `events_requested` is missing, `events_delivered` should remain unaltered?
- (Phil) If `events_requested` is not asserted, then it means that the Receiver is not specifying which events
- (Phil) You could be requesting events A, B, and C. But you've only paid for A and B, so the Transmitter only includes A and B in the stream
- (Apoorva) In the current spec, the `events_delivered` is a pure intersection of `event_requested` and `events_supported`
- (Phil) We then need to update this "intersection" language
- (Phil) `supported` describes technical capabilities, `delivered` means what you actually get
- (Atul) `supported` could also mean just what is desired

## Action Items