[Openid-specs-risc] call notes

[Atul Tulshibagwale]

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

Atul

-- 

 Atul Tulshibagwale

 CTO

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

--
WG Meeting: 2025-05-06 <#Agenda>Agenda

   - Using the term "wildcard" in complex subject examples. PR
   <https://github.com/openid/sharedsignals/pull/251>, Issue
   <https://github.com/openid/sharedsignals/issues/197>
   - Pushpull draft
   <https://datatracker.ietf.org/doc/draft-tulshibagwale-saag-pushpull-delivery/>
   review in IETF Saag.
   - Issuing the "Working Group Last Call"
   - Push delivery authorization
   - Authorization for "well-known" URL

<#Attendees>Attendees

   - Apoorva Deshpande (Okta)
   - Shayne Miel (Cisco)
   - Atul Tulshibagwale (SGNL)
   - Tushar Raibhandare (Google)
   - Martin Gallo (independent)
   - Mike Kiser (SailPoint)
   - Yair Sarig (Omnissa)
   - Jen Schreiber (Workday)
   - Brian Soby (AppOmni)
   - Thomas Darimont (OIDF)
   - George Fletcher (Practical Identity LLC)
   - Stan Bounev(VeriClouds)
   - Sean O'Dell (Disney)

<#Notes>Notes <#Wildcards>Wildcards

   - (Apoorva) Supportive of the change, but the word "wildcard" might be
   confusing, because it doesn't follow the typical wildcard characters (e.g.
   "*")
   - (Shayne) It looks like Sean resolved them, but I'll reopen them.
   - (Shayne) How do you feel about leaving the word wildcard in at the top
   (where we describe the behavior)
   - (Shayne) People might be searching for the word wildcard, so we should
   keep the word somewhere. E.g. keep it in the description, but take it out
   of the individual examples
   - (Apoorva) We're specifying examples for contentious claims?
   - (Shayne) It's not contentious because it is not ambiguous, it is
   specified clearly in the spec, but we're clarifying the usage in examples
   - (Apoorva) It is contentious if the claims conflict with each other
   - (Atul) I don't believe there is a conflict anywhere
   - (Apoorva)
   - (Mike) I've been asked "How do I specify a group of identities". I
   agree that the world "wildcard" is confusing. The way the spec works, if
   you don't specify something it is like a wildcard (i.e. it matches
   everything).
   - (Yair) I understand Apoorva's point, because I also was looking for
   the wildcard characters. This is more like partial specification of the
   subject.
   - (Yair) I can see it go both ways - it might be called wildcard, or not.
   - (Apoorva) I agree that the description sentence on line 318 can say
   "wildcard" as it does right now, but remove it from everywhere else.

<#Pushpull-draft>Pushpull draft <#Issue-WGLC>Issue WGLC

   - (Tushar) The flow control issue
   <https://github.com/openid/sharedsignals/issues/249> could be addressed
   before v1Final

<#Flow-control-issue>Flow control issue

   - (Apoorva) Is it a blocker?
   - (Tushar) Implementations can define their own behavior, so it doesn't
   block.
   - (Yair) We have a "stream disabled", so there is no real requirement
   for pause. So if the events are paused, then you don't know how many events
   the transmitter is going to retain. So without defining this behavior we
   are making the behavior of "pause" unreliable
   - (Sean) Use-case for pause: You are going through a massive HR changes,
   and you don't want to flood the streams with events
   - (Sean) This is also important for reconciliation, how many events do
   you keep in the stream when it is paused
   - (Shayne) I don't think we want to specify the number, but the proposal
   is that there should be a way to communicate what the limit is.
   - (Yair) There are two conditions: Receiver not keeping up, or the
   stream is paused.
   - (Tushar) Yes, there are two sides:
      - I'm a receiver, and I can only handle so many events
      - I'm a receiver and I'd like to tell the receiver in terms of time
      or amount of data / number of events that I'll be holding
   - (Apoorva) This also has SLA / SLO implications, and may not be easy to
   implement
   - (Brian) In terms of buffer, people can have total size, which may not
   be useful to the receiver, so practically it might not be useful
   - (Tushar) What if a Transmitter has higher-lower priority events?
   - (Tushar) So the configuration could be per-stream to address the
   priority issue
   - (Yair) This is what happened in draft-2 and we are still kicking the
   can down the road.
   -

<#Push-delivery-authorization>Push delivery authorization

   - (Mike) The spec says that authorization is optional for push delivery.
   Is everyone OK with that?
   - (Yair)
   - (Shayne) One reason to require an authorization header is to make it
   easier to defend against DoS attacks
   - (Shayne) Security policy may dictate all endpoints need authorization

<#Can-the-well-known-URL-be-protected-or-does-it-need-to-be-unprotected>Can
the "well known" URL be protected or does it need to be unprotected

   - (Mike) People are asking about this
   - (Yair) There is no requirement to be unprotected. (We discussed this
   earlier)
   - (Yair) The well-known spec also doesn't require it to be unprotected.
   - (Apoorva) If it is protected then there has to be a handshake even
   before the metadata is obtained
   - (Atul) The SGNL implementation has the well-known url protected

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