# WG Meeting: 2023-09-05
## Agenda
- https://github.com/openid/sharedsignals/pull/108
- https://github.com/openid/sharedsignals/pull/109
- https://github.com/openid/sharedsignals/pull/101
- https://github.com/openid/sharedsignals/pull/87
- How do we make new kinds of events available?
- SSF Service general reference instead of Transmitter / Receiver

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Phil Hunt (Independent ID)
- Erik Karlinsky (Okta)
- Apoorva Deshpande (Okta)
- Andrii Deinega()

## Notes
### [Stream ID uniqueness PR](https://github.com/openid/sharedsignals/pull/108)
- (Atul) Should we clarify that the uniquness is per Transmitter?
- (Phil) Should we say uniqueness per "SSF Service"
- (Atul) A Receiver cannot guarantee uniqueness if it connects with multiple Transmitters
- (Shayne) We cannot generalize Transmitter / Receiver to "SSF Service" because there are some things each one can do that is unique
- (Erik) Context: Can a Receiver have the same stream ID from multiple Transmitters
- (Shayne) That was an ambiguity in the spec. The intent was to specify uniqueness across all streams in a Transmitter
- (Phil) There are many places in the spec that could need to be changed if we have to add language that is specific to Transmitter or Receiver
- (Shayne) Can we move this dicussion as a separate topic?

### [format PR](https://github.com/openid/sharedsignals/pull/87)
- (Shayne) Please review

### [`events_delivered` is not a subset](https://github.com/openid/sharedsignals/pull/109)
- (Apoorva) Phil raised this issue the last time

### [Decoupling SSF and OAuth](https://github.com/openid/sharedsignals/pull/101)
- (Atul) I have open questions about the OPRM spec on the OAuth mailing list
- (Apoorva) should we remove this part entirely from the metadata
- (Atul) I'm OK with removing OAuth references from the metadata
- (Atul) Should `authorization_schemes` simply be a list of URNs?
- (Apoorva) Should we have some admin visible field other than URN that we have in the metadata?
- (Apoorva) Where is the documentation when a specified scheme does not map to an RFC?
- (Shayne) Then should the Transmitter have out of band mechanisms to specify to Receivers
- (Apoorva) As long as there is an understanding between the trusted parties

 "authorization_schemes": [
      {
        "spec_urn" : "<urn>"
      },
      {
        "spec_urn" : "<urn2>"
      }
]

- (Phil) Do we want to be able to use OpenID client relationship in configuring SSF to provide capabilities such as logout?
- (Apoorva) I think that fits within these plans as a use case
- (Andrii) OpenID Connect can use only front channel for initiating logout from an RP to an OP, and the front channel is unreliable by its nature. The SSF spec is exciting for this as a use case.

### How do we make new kinds of events available?
- (Shayne) Do we want an IANA registry?
- (Phil) The security events committee decided against a registry in favor of URNs that could uniquely identify the event type.
- (Apoorva) OpenID logout is a command, not an event
- (Phil) Disagree. It is a statement of some event that occurred. Otherwise, there are arguments that "you can't tell me what to do".
- (Shayne) Can we at least provide links to public event documentation from the SSF docs?
- (Phil) There are discussions with SCIM about registering events in IANA
- (Apoorva) Do we need to switch event identifiers to URNs instead of URLs like they currently are in RISC and CAEP?
- (Shayne) Maybe we should make the event identifier a URI so it can be either URL or URN
- (Shayne) Either way, we should make it clear in the spec how one might create new kinds of event
- (Phil) A "best practices" section would be nice for several things

### SSF Service general reference instead of Transmitter / Receiver
- (Phil) Trouble when implementing because spec doesn't recognize that you can be both a Transmitter and Receiver
- (Apoorva) Saw the same thing. Receiver config is completely skipped in spec.
- (Phil) Problems:
- If doing PUSH, Receiver has to be set up first, then Transmitter has to be connected
- If doing POLL, Transmitter has to be set up first, then Receiver has to be connected
- (Apoorva) It is hard for customers to know how to set up a Receiver
- (Apoorva) We don't mention when is the right time to start transmitting
- (Phil) This is related to the issue about when does the stream start
- (Shayne) Maybe a "start the stream" event, like the verification event

## Action Items
- Apoorva to clarify scope of uniquness to be per transmitter
- Apoorva to update PR#108 to have more normative language
- Phil to talk to IANA about setting up an OpenID/SSF namespace