`events_supported` field added to .well-known/ssf-configuration response

[beyond-james-slocum]

In section 6 "Transmitter Configuration Discovery", it would be helpful to have the events_supported field from the "Stream Transmitter Configuration" present to allow supported event discovery from a receiver application. This would prevent errors during integration between a receiver and transmitter as it would be provide a standardized way to getting the list of events its possible to receive.

Under section 6.1, add

events_supported

OPTIONAL. An array of URIs identifying the set of events supported by the Transmitter for a Receiver. If omitted, Event Transmitters SHOULD make this set available to the Event Receiver via some other means (e.g. publishing it in online documentation).

This will also assist in the Receiver generating the events_requested as it "A Receiver SHOULD request only the events that it understands and it can act on."

Example: GET https://ssf.example.com/.well-known/ssf-configuration

  "spec_version": "1_0-ID3",
  "issuer": "https://ssf.example.com/",
  "jwks_uri": "https://ssf.example.com/.well-known/jwks.json",
  "delivery_methods_supported": [
    "urn:ietf:rfc:8936"
  ],
  "events_supported": [
    "https://schemas.openid.net/secevent/ssf/event-type/stream-updated",
    "https://schemas.openid.net/secevent/ssf/event-type/verification",
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked",
    ...
    "https://schemas.openid.net/secevent/risc/event-type/credential-compromise",
    "https://schemas.openid.net/secevent/risc/event-type/opt-in",
    "https://schemas.openid.net/secevent/risc/event-type/opt-out-initiated",
    "https://schemas.openid.net/secevent/risc/event-type/sessions-revoked"
  ]
}

[vivshankar]

Thanks @beyond-james-slocum . I completely agree with this.

Have you seen the discussion here:
#219

It hasn't had much movement.

[beyond-james-slocum]

@vivshankar yes, I saw it had not moved much, so I thought it would be best to address it directly, and generate a pull request with the suggested change to have firm ground to start the debate on. I think it is generally accepted that we need "something" but I can understand if we ant to debate about OPTIONAL vs RECOMMENDED for the field, or if a discovery endpoint is complex enough to warrant its own endpoint definition. (e.g. /.well-known/ssf-events-supported as REQUIRED) etc...

Pull Request: #225

[vivshankar]

@beyond-james-slocum Thanks! Happy for it to be optional given there are several implementations out there. I guess it could be treated similar to scopes_supported and code_challenge_methods_supported in the OIDC/OAuth discovery payloads.

[FragLegs]

I am going to close #219 as a duplicate of this and continue the conversation here. Thank you for putting together a pull request.

[FragLegs]

I spent some time thinking about it, and I think I’ve come up with a possible scenario in which having events_supported in the TransmitterConfig instead of the StreamConfig would be useful:

Imagine a future where SSF has achieved wide adoption. CompanyA has a receiver implementation and one of their customers wants to set up a stream between one of that customer's security tools (CompanyB) and CompanyA. They need to plug in the well-known, their credentials, etc. At the same time, they also need to set up routing rules for what happens for each event type. I imagine it would be useful for CompanyA to be able to list only those event types that CompanyB can send in the UI when the customer is setting all this up.

If we make this change, we should deprecate the use of events_supported in the StreamConfig

[beyond-james-slocum]

I think there is still a use case to have them in both places. In the transmitter config, since anyone can see those, you can list your "universally supported" public events, things like the CAEP and RISC event sets. Once a receiver registers and sets up its stream, its true that the list might be redundant. However you can imagine a "tight partnership" or two companies that are subsidaries of a parent that might want to share propitiatory events that they might not want publicly discoverable. This is where that list could go once the receiver was marked as special by their system.

Also it's already optional, so if a company is not using the system in this way, they can simply disregard.

[thomasdarimont]

I think it is useful to have “event_types_supported” at the level of “transmitter metadata” as well as for stream configuration.
The transmitter metadata could list all event types generally supported by the transmitter. The event types actually supported by a stream can be a smaller subset of the transmitter metadata event types.
Background: Vendors could allow finer settings at stream level depending on the client / subscription / plan and further restrict the available event types for a client.

[tulshi]

See notes from the call on 2/11