[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from yesterday's WG meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230404>.

Thanks,
Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>


Agenda

   - https://github.com/openid/sharedsignals/issues/19
   - https://github.com/openid/sharedsignals/issues/39
   - https://github.com/openid/sharedsignals/issues/36
   - https://github.com/openid/sharedsignals/issues/32
   - caep.dev demo, sponsorship and support
   - Expectations between a Transmitter and a Reciever (does the
   Transmitter need to support different set of events depending upon a
   Receiver)

<https://hackmd.io/ag7temXMT22Euj5DYKwzyw#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Eric Karlinsky (Okta)
   - Shrinivas Challa (Workday)
   - Greg Brown (Axiad)
   - Debora Comparin (Thales)
   - Phil Hunt
   - Tim Cappalli (Microsoft)
   - Frank Taylor (VMWare)
   - Nancy Cam Winget (Cisco)

<https://hackmd.io/ag7temXMT22Euj5DYKwzyw#Notes>Notes
<https://hackmd.io/ag7temXMT22Euj5DYKwzyw#caepdev>caep.dev

   - SGNL is sponsoring caep.dev today—open to more sponsors.
   - caep.dev is a SSF transmitter.
   - Will be live on Tuesday April 11

Feedback:

   - This is awesome!
   - Suggestion is to make it more clear that CAEP is an event profile and
   SSF is the transmission framework.

Q: What does it mean to be a sponsor?

   - Supports the development. Roadmap: Open Source receiver tooling.
   - Ask: Provide feedback.

Q: Should we focus so heavily on CAEP, versus SSF generally?

   - Shayne Miel
   - +1 Eric Karlinsky
   - +1 Tim Cappalli - We are already fighting confusion about what CAEP
   is… CAEP is a list of events, that’s it. Perhaps we should “brand” this
   site as an SSF transmitter.
   - Phil Hunt - A general purpose SSF site would be preferred, as
   something that OpenID Foundation would back.

No objections raised to OIDF supporting the launch of this website via a
press release, e.g…
<https://hackmd.io/ag7temXMT22Euj5DYKwzyw#Transmitter--Receiver-expectations-on-%E2%80%9Cevents_supported%E2%80%9D>Transmitter
/ Receiver expectations on “events_supported”

   - A Transmitter may put different events_supported in each stream
   configuration it creates with even the same Receiver (or different
   Receivers)
   - events_supported was supposed to be describing what events the
   Transmitter is technically capable of supporting
   - events_delivered is supposed to describe what the stream can contain
   - Q: (Eric) Is events_delivered just an intersection of events_supported
   and events_requested?
   - A: What features may determine which events are delivered? It could be
   the license of the Receiver, based on an authorization
   - The stream configuration endpoint appears like a static endpoint in
   the metadata. Would there be a separate URL for each stream configuration
   in that case?
   - The response will be dependent on the token, not necessarily the URL
   - It will help to clarify in the spec that the output of
   “events_delivered” is within the purview of the Transmitter based on the
   business relationship between the Receiver and Transmitter
   - There seems to be a conflict between “self discovery” (what was
   intended a few years ago) and the need for hiding the list of events
   supported (for security reasons)
   - How do you discover new event types supported by the Transmitter
   without having to supply an authorization token?
   - Is automation the only driver there? An admin could need to see this
   in a UI for planning / policy definition purposes
   - How would the Receiver know what is possible versus what is available
   to it?
   - Is the discovery “offline” / out of band? How much discovery is worth
   having in the protocol?
   - In a SSF Gateway for example, the list of supported events may depend
   on the tenant that the requests are being routed to.
   - Leaving the language neutral (as it is now) makes both possible
   - The present spec specifies “events_delivered” as the intersection of
   “events_supported” and “events_requested”, but the spec should clarify that
   it may not have everything from the intersection
   - What happens when a Transmitter dynamically is able to support a
   different set of events from what was shared earlier?
   - Receivers must poll the Transmitter (using Get Stream Configuration)
   to find out new events that become available
   - Should we clarify that “events_supported” may be a subset of
   everything the Transmitter technically is capable of supporting? Yes (some
   on the call agreed)

<https://hackmd.io/ag7temXMT22Euj5DYKwzyw#Action-Items>Action Items

   - Create an issue to: Clarify “events_delivered” is not necessarily the
   entire intersection of “events_supported” and “events_requested”
   - Create an issue to: Add text to clarify that “events_supported” may
   not always be everything that the Transmitter is technically capable of
   supporting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230405/dfd0a2e1/attachment-0001.html>