# WG Meeting: 2023-08-22
## Agenda
- supported_scopes / OAuth server discovery discussion
- (smiel) Why do we have a `format` field in the Stream Configuration? [PR 87 discussion](https://github.com/openid/sharedsignals/pull/87#discussion_r1276951345)

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Mike Kiser (SailPoint)
- Phil Hunt (Independent ID)
- Eric Karlinsky (Okta)
- Steve Venema (ForgeRock)
- Victor Lu (Guest /)
- Yair Sarig (VMWare)
- Apoorva Deshpande (Okta)

## Notes
### Supported Scopes issue
- Adding "supported_scopes" causes SSF to require OAuth
- This is not considered to be reasonable for SSF
- IdPs may defined different authentication / authorization mechanisms for SSF
- Adding any authorization specific information in SSF, it may not be scalable for other mechanisms
- OAuth discovery can be used instead for finding scopes and authorization servers
- Server can respond with the "WWW-Authenticate" response to unauthenticated requests
- (Phil) Some implementations require tokens for authorization of Poll or Push endpoints. Those implementations already require OAuth. If an admin updates one or more streams, does the admin require different tokens?
- (Phil) Does the draft specify anything about stream with the bearer token?
- (Shayne) With the updated draft (multiple streams), the endpoint is in the URL and not related to the token.
- (Phil) In 8935/8936 (Poll/Push) drafts, there is no information in the token
- You could specify the endpoint per stream
- (Phil) that would be required if we did that, do we need to add anything in the spec
- (Phil) We're practically in an OAuth world, so it may not be a bad idea to have some simplification in the spec
- (Apoorva) This is not the only mechanism, there will be others, so we should have decoupling
- (Shayne) Should we remove all authorization related information from the SSF spec?
- (Phil) Some implementations use a bearer token incorrectly (without the "Bearer" prefix in the header)
- (Yair) I recommend we decouple the authorization from the SSF spec
- (Steve) Do we need to ...
- (Apoorva) My PR proposes that the Transmitter Configuration Metadata can specify the authorization schemes
- (Yair) If someone has subscribed to a service, they should know how to authorize their requests
- (Phil) Some of this work has been done in the SCIM working group
- (Phil) We should follow a model similar to SCIM in SSF, unless we want to simplify the spec by requiring one pattern, but that might be a tradeoff. Systems that receive events may be highly varied (including IoT), so flexibility is good
- (Phil, Apoorva) We should perhaps soften the "Should" in Section 8 to "May". Apoorva's PR removes this section.
- (Phil) We should have some discussion on authorization in the Security Considerations section. Event delivery, administration, configuration updates, status, etc.
- (Yair) We should mention the desired security properties of endpoints
- (Apoorva) Why should the spec bother with this?
- (Phil) Hypothetical example: client can auth to say, Google, using 3 ways, mTLS, signed event or bearer token
- (Apoorva) WG made the decision to not have signed SETs, this also ties back to the security. "jwks_uri" was REQUIRED, and now it says OPTIONAL
- (Phil) That may be a mistake, because SCIM requires it. Events are stored for historical use, and knowing that those events are legitimate.
- (Steve) From my perspective, interoperability is important, and this is fundamental to it. Should we have different profiles? E.g. a bearer token profile?
- (Steve) We won't have to have these profiles immediately, but we can do this as a part of the interoperability work ahead.

### format PR
- (Shayne) Do we want the format field in the stream configuration?
- (Apoorva) Adding the format in the stream configuration breaks the flexibility that a Transmitter can provide different event types with different subject formats
- (Phil) If you use the IETF sub_id format in SSF, then this is simple. Multiple events can be expressed differently. Transmitter and Receiver need to negotiate how specific events will be formatted
- (Phil) At scale, there is a challenge if each Receiver desires a different format for the subject.
- (Shayne) When a Receiver creates a stream, they specify the event_types and the format for the stream as a whole
- (Shayne) sub_id is abstracted away from the event type now, it is a top-level claim now in the SET
- (Phil) Operationally, we should be able to create a stream with different event types, for some class of events you may want certain sub_id formats. It might be too complex
- (Apoorva) From an implementation point of view, one event could have two different sub formats. Does the Transmitter skip events that doesn't match the format?
- (Phil) If the Receiver and Transmitter don't have agreement, the events may get ignored anyway.
- (Atul) Should we skip having the "format" field in the stream configuration right now?
- (Phil) Or we could go with a fallback model
- (Shayne) Why would it be hard for the Receiver to not handle different event types. Why does the receiver need to know in advance
- (Steve) Implementing all formats may not be that hard
- (Phil) They may not have the data to handle this
- (Yair) Receiver may have information about the events, but the same user may be identified in multiple ways, the Transmitter may have multiple ways of specifying the same event. How would the Transmitter know
- (Phil) The same subject even in the same format may be identified differently. The Transmitter and Receiver must have agreement in advance on how to identify the same user
- (Shayne) Having the format field doesn't really solve the agreement problem because of what Phil said right now
- (Phil) A common understanding of the subject is a requirement
- (Atul) Is this is a good summary: "While it's desirable to specify the format, there doesn't seem to be a simple way to do this, so we should skip the format field from the stream configuration right now"?
- (Shayne) If we keep the format field, then we must specify what the Transmitter needs to send an event in an unsupported format
- (Phil) When the stream gets setup, the Receiver specifies the format, but the Transmitter specifies the format it supports. The Receiver can agree to the formats then they continue, else the Receiver ends the stream
- (Atul) There could be a race condition that multiple events are sent before the Receiver ends the stream
- (Phil) We could make this a part of the discovery
- (Steve) So should the next implementer's draft should remove the format field from the configuration?
- (Phil) So it would be an out-of-band issue. This could become an interop problem
- (Shayne) Any implmentation should support all formats in the SSF spec
- (Steve) Can we add non-normative text that this is a current issue with the spec.

## Action Items
- Phil to review spec and find out if the authorization is decoupled from OAuth - issue preferred, but email is OK
- Discuss SET signing issue in next call, anyone with background information please email the group
- Shayne to update PR to remove the "format" field from the stream configuration.