WG Meeting: 2025-05-06

# WG Meeting: 2025-05-06 ## 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 - 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 ### 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 ### Issue WGLC - (Tushar) The [flow control issue](https://github.com/openid/sharedsignals/issues/249) could be addressed before v1Final ### 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 - (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 - (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