WG Meeting: 2023-08-29

# 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