<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 219 <br>

Issue Title: Add event_types_supported to the SSF transmitter metadata <br>

https://github.com/openid/sharedsignals/issues/219 <br>

<br>

Comment: @FragLegs I see what you mean. The main issue is there is no prescribed mechanism available to discover the event types supported by a transmitter. So the only mechanism that appears to exist for a receiver is to - 1. Find product documentation that

 indicates the list of event types (or speak to someone in the product support/dev team) 2. Supply the desired list in `events_requested`. The transmitter can and would respond with `events_delivered` that indicates exactly those events that will be delivered

 to this stream. This could be based on the subscription plan etc. So with my proposal, this is what the receiver would do - 1. Look up ssf-configuration for events_supported 2. Include events of interest in `events_requested` 3. Transmitter responds with the

 ones that will be delivered It eliminates a non-prescriptive mechanism of discovering events that are supported by the transmitter, while retaining the ability to filter by subscrption plan etc. Also, in the event that the receiver doesn't provide events_requested,

 the transmitter makes the appropriate decision on which events would be delivered, which may be all that are allowed based on the subscription plan entitlement etc.

</body>

</html>