[Openid-specs-risc] call notes

[Atul Tulshibagwale]

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

Atul

-- 

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
---
WG Meeting: 2025-02-11Agenda

   -

   Build is broken
   -

   Risk level change pull request
   -

   stream_id character set
   <https://github.com/openid/sharedsignals/issues/229>
   -

   Other issues
   -

   Open PRs

Attendees

   -

   Atul Tulshibagwale (SGNL)
   -

   Yair Sarig (Omnissa)
   -

   Thomas Darimont (OIDF)
   -

   Shayne Miel (Cisco)
   -

   Colton Chojnacki (Beyond Identity)
   -

   James Slocum (Beyond Identity)
   -

   Martin Gallo (Individual)
   -

   Tushar Raibhandare (Google)
   -

   Brian Soby (AppOmni)
   -

   Apoorva Deshpande (Okta)

NotesBuild is broken

   -

   Ruby is not found - possibly removed from GitHub

Risk level change pull request

   -

   New pull request merged

Stream_id character set

   -

   Atul marked it as v1Final
   -

   (Shayne) we should mention that it is "recommended" to preserve backward
   compatibility

Other issues

   -

   Tushar still working on stream ttl pull request
   <https://github.com/openid/sharedsignals/pull/222>

Open PRs

   -

   events_supported in metadata

   <https://github.com/openid/sharedsignals/issues/224>
   -

   (Yair) Is there an obligation / commitment that you are going to allow
   the event to a receiver?

   -

   (Apoorva) Should we provide a precedence order to 'events_supported' in
   the metadata versus the 'events_supported' in the stream configuration

   -

   (James) In a headless way, a receiver has no way to know what events are
   available to them before creating the stream

   -

   (Apoorva) Should we deprecate the events_supported in the response to
   the stream configuration calls?

   -

      (Atul) Too drastic?
      -

      (Shayne) It's OK to do it since we are not putting a timeline
      -

      (Apoorva) Should we say 'not recommended for new implementations'
      instead?
      -

      (Shayne) Should we say "should not" instead of "not recommended", we
      have used that language in the backwards compatibility section
      -

      (Thomas) events_supported in metadata will leak implementations to
      other implementers.
      -

      (James) We might be conflating two use cases, because by the time a
      receiver has the stream, they already know which events they want.
      -

      (Apoorva) Making it headless was not the aim. We have said that
      discovery is a shakehand between two consenting parties.
      -

      (Atul) There could be events that a transmitter supports which are
      not in the events_supported list in the metadata
      -

      (Thomas) This will work
      -

      (Apoorva) So this is still not headless
      -

      (Atul) For some use cases it is headless, for those not mentioned in
      the events_supported, it is not.
      -

      (Shayne) We need to call out that in the spec.
      -

      (Apoorva) So are we saying that the stream configuration response
      will have all events supported?
      -

      (James) yes, we should say that
      -

      (Shayne) The spec says that events_delivered is a subset of
      events_supported and events_requested, but those two are optional
      -

      (Tushar) What is the use case for having events_supported outside the
      stream if not all event types are there?
      -

      (James) It's to be agnostic to the implementer, so a transmitter can
      advertise which events it supports
      -

      (Shayne) more optionality is more incompatibility
      -

      (James) Good point about the subset of optional fields being
      nonsensical
      -

      (Yair) If the metadata is a singular endpoint for the whole
      transmitter, it might be valuable, but otherwise it is not
      -

   (Atul) What will break if we don't add this capability

   -

      (James) It prevents receivers from discovering transmitter
      capabilities
      -

      (Yair) If we want this to be viable, then we need more than just
      events_supported.
      -

      (Apoorva) Yes, e.g. authn and authz
      -

      (James) Many things have been left out of this spec, authn/authz, but
      there are ways one can design a transmitter to do that outside the spec
      -

      (Shayne) It is designed for existing business cases. People are
      implementing around current business cases. This change would be adding a
      "made up" business case
      -

      (James) If we use existing business cases as the model, then is the
      "tail wagging the doc"
      -

      (Atul) We could start with new use cases and see what we need to
      achieve that
      -

      (Tushar) Even in the headless case, the receiver knows all the event
      types it supports, and the Tx can just respond with the ones it supports.
      -

   (Atul) Should we defer to after v1Final?

   -

      (Apoorva, Yair, Tushar) yes
      -

   (Thomas) What is the expected behavior of a transmitter when the
   receiver specifies events_requested types that does not include any that
   the transmitter supports

   -

      (Yair) events_delivered will be empty in that case in the resulting
      stream
      -

      (Shayne) The receiver can still update the stream configuration and
      add the events it wants
      -

      (Thomas) This works, perhaps this should be explicitly listed in the
      spec, it might work better than adding it in the metadata
      -

      (Brian) I'd rather have an endpoint where this can be discovered.

Action Items

   -

   (James) to update the events_supported PR to
   -

      add the deprecation language to the events_supported field in the
      stream configuration response.
      -

      note that transmitters may support more events than those mentioned
      in events_supported
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250211/76e93e3e/attachment-0001.htm>