# WG Meeting: 2022-06-06
## Agenda
- [#60 Are Subjects Required in SSF Events](https://github.com/openid/sharedsignals/issues/60)
- [#45 Before a Receiver creates a stream...](https://github.com/openid/sharedsignals/issues/45)
- [#36 Should poll URL be specified...](https://github.com/openid/sharedsignals/issues/36)

## Attendees
- Atul Tulshibagwale (SGNL)
- Stan Bounev (VeriClouds)
- Steve Venema (ForgeRock)
- Peter Travers (Beyond Identity)
- Eric Karlinsky (Okta)
- Apoorva Deshpande (Okta)
- Edmund Jay ()

## Notes
Issues picked up for discussion today are those tagged as bugs in GitHub

### Issue #60
- Are subjects always explicitly added to a stream? We had disucssed this topic a few weeks ago.
-
### Issue #45
- We need not have a way for Receivers to discover event types before creating a stream.
- Instead, we can clarify that a Transmitter should ignore any event types in "events requested" from a Receiver Create Stream request that it doesn't understand.
- Similarly, a Receiver should only rely on the "events delivered" parameter of the stream configuration to understand which events it can expect from a Transmitter, regardless of what it has requested.

### Issue #36
- Modify the spec to clarify that "delivery" is not always Receiver Supplied.
- The "delivery_method" is always Receiver Supplied
- The "url" is Receiver supplied for "Push" method, and Transmitter supplied for the "Poll" method

### General Discussion
- [Apoorva] What is the guidance for implementers? Should they use the current Implementer's Draft or the new draft that we will propose to become the next Implementer's draft
- [Atul] Since most implementations are starting now, and we are going to propose the new draft to become the next Implementer's Draft very soon, we should use the new draft and not the current Implementer's Draft
- [Eric] Qustions about AuthZ and AuthN: The spec requires that the Transmitter create a stream with a unique ID, based on the request to create the stream. The Transmitter is expected to use the AuthN information. If we were to use a "client ID", then there would need to be only one stream per client. If somehow the stream ID could be specified as a part of the Receiver Create Stream request, then
- [Peter] An OIDC client ID should not be required to create a stream.
- [Eric] The client ID is really the only unique identifier relating to the Receiver that is available to the Transmitter
- [Apoorva] Spec today does not clarify how a Transmitter / Receiver should agree on a Stream ID
- [Peter] Are all fields in the Stream Configuration required unless specified as optional? Would this observation apply to the entire spec?

## Action Items
- Atul to update spec to resolve issue #45
- Atul to update the spec to resolve issue #36