[Openid-specs-risc] Call notes

Tue Apr 15 18:04:12 UTC 2025

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

Thanks to all who participated,
Atul

-- 

 Atul Tulshibagwale

 CTO

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

---
WG Meeting: 2025-04-15Agenda

   -

   event_data in SSF or CAEP/RISC?
   -

   Flow control (https://github.com/openid/sharedsignals/issues/249)

Attendees

   -

   Atul Tulshibagwale (SGNL)
   -

   Yair Sarig (Omnissa)
   -

   Stan Bounev (VeriClouds)
   -

   George Fletcher (independent)
   -

   Tushar Raibhandare (Google)
   -

   Martin Gallo (independent)
   -

   Rob Starling (Google)
   -

   Shayne Miel (Cisco)
   -

   Jen Screiber (Workday)

NotesEvent Data in SSF?

   -

   Why was it put in the CAEP and RISC spec?
   -

      (Shayne) It's because there is no suitable place in the SSF spec
      where it could be put
      -

      (Shayne) It should be in the SSF spec so that it can be used by any
      spec leveraging SSF
      -

   Atul to look into adding to SSF
   -

   (Rob) where would you put this in the SSF spec?
   -

      (Atul) perhaps a new section like "4.2.3"?
      -

   (Rob) Two event types might define the same field as something different.
   -

   (Rob) There may be reserved names that are in the SSF spec.
   -

   (Rob) We are then specifying that an event must be extensible over the
   base event.
   -

   (Rob) What is the contract relationship between the event descriptions
   in the CAEP/RISC/SCIMEvents specs over the SSF spec.
   -

   (George) If we needed, we could create a registry, but because the spec
   is not final, defining an optional claim for event data in SSF is probably
   not going to step on anyone's toes. You could look at the SSF event as
   being an abstract class.
   -

      (Rob) So is the intent for the SSF event description to be a
      superclass.
      -

      (Rob) If we think the former is fine, then we should document that
      -

      (George) So the question is whether a sub-spec should be able to
      transmit something that can transmit a "non-SSF" event?
      -

      (Jen) What do we mean by an SSF event?
      -

      (Rob) Does this group have control over the CAEP/RISC/SCIM events?
      -

      (all) not SCIM
      -

      (George) We could add language to the SSF spec to say that our
      "events" claim profiles the events claim in the SET spec.
      -

      (Shayne) Do we want to put "event_data" inside the "events" claim?
      -

      (Shayne) Another option that was proposed was that there could be
      separate field in the SET called "events_data", and each key in
that field
      could be the unique key from the "events" field.
      -

      (Shayne) What about having to put OCSF events?
      -

      (Jen) Some enterprises already use custom events
      -

      (George) The other mechanism would be to reserve a claim name (e.g.
      "event_data") within the scope of the SETs. We could register it
in the SET
      IANA registry.
      -

      (Rob) We talked about two alternatives - define the "event_data"
      within the events claim, another is to have an alternative "events_data"
      claim that has event data about all events.
      -

      (George) We could say that "when you are defining new events, then
      you must use "event_data" field to put additional fields"
      -

      (Rob) We could just give a concrete example of how to use "event_data"
      -

      (Yair) An event is that in the "device_compliance_change" event, one
      might want to include some details about how the device is non-compliant.
      -

      (Tushar) Couldn't you use "reason_admin", "reason_user" for that
      purpose?
      -

      (Jen/Shayne) That was overloading those fields
      -

      (Jen) We should just evaluate the specific event type definition to
      say whether we need additional fields
      -

      (Shayne) If there is some data that needs to be added, we could just
      add those as additional fields in the event. Receivers can
ignore it unless
      they can deal with it.
      -

   (Atul) Should we punt on this right now?
   -

   (Tushar) They could subclass the event and specify it for their
   receivers. The URI that specifies the event would change in that case
   -

   (Yair) If you change the URI, then you are making it incompatible to
   receivers who expect the standard event.
   -

   (Tushar) The only thing is that it loses the structure.
   -

   (George) It's fine to do this within an enterprise, but when you have a
   SaaS product that wants to rely on the additional data, then we might need
   more agreement than within one enterprise.
   -

   (George) The risk in not specifying this is that you get mutually
   conflicting fields, but we might not need to solve it right now (for 1.0)
   -

   (Atul) Should we punt on this issue for v1Final?
   -

   (George) Non-normative text about being able to add custom fields could
   be useful
   -

   (George) Specs like OAuth have such language, which say that if you
   don't understand those fields, you should ignore them. This is better than
   the spec being silent, which could lead to different implementations. I've
   seen this happen where people use very hard-coded / rigid parsers, so
   having non-normative text will help.
   -

   (George) This could be tested in interoperability tests too.
   -

   (Rob) I'd support having more structure, including saying that receivers
   should ignore fields they don't understand.
   -

   (Atul) Let's go with the minimum that we agree on, which is that
   receivers should ignore event fields they don't understand.

Flow Control

   -

   (Tushar) Right now there is no language about how long a transmitter
   stores the data if it fails to deliver events to the receiver. Example
   situations - receiver down (push), paused stream, receiver not pulling
   frequently enough (pull)
   -

   (Tushar) Another aspect is that there may be busy times for a
   Transmitter, but there is no way for a receiver to express how much traffic
   it can handle
   -

   (Yair) Added two links to previous issues that we discussed that are
   related to this
   -

   (Yair) I don't know how much metadata we should be adding. Can we
   instead have error codes with an expected backoff behavior
   -

   (Yair) there are standard http status codes for that (429)
   -

   (Yair) agree about the first point, because otherwise the Transmitter
   might be expected to keep the data forever
   -

   (George) If you are starting to get backed up, then is there a priority
   of events that you want to receive? Can you create multiple streams with
   different priorities?
   -

   (George) There might be some events that you don't want to use and
   others that are less critical and possibly ok to lose.
   -

   (George) If we are adding flow control, then we should have some way of
   specifying this.
   -

   (Atul) We could add language that specifies creating different streams
   for different priority events
   -

   (Yair) Transmitters can end up accumulating events in multiple
   situations, so we need to add language about what the transmitter can do.
   -

   (Atul) We should add language to the spec to add a per-stream limit of
   how much data / how many events / time period a Transmitter can hold, and
   add some language that recommends the use of multiple streams for different
   priorities
   -

   (Shayne) Who decides the priority of events?
   -

   (George) The receiver needs to make a determination which events are
   important to it and it doesn't want to drop. So if a receiever gets
   overloaded, then it can drop the low-pri stream.

Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250415/f0456bda/attachment-0001.htm>