<div dir="ltr"><div dir="ltr">Hi all,<br><div>Thanks to those who attended, here are the notes for today's call. They are also stored <a href="https://hackmd.io/@oidf-wg-sse/wg-meeting-20241203">here</a>.</div><div><br></div><div>Atul</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><div dir="ltr" style="margin-left:0pt" align="left"><table style="border:none;border-collapse:collapse"><colgroup><col width="165"><col width="160"></colgroup><tbody><tr style="height:74.5pt"><td style="vertical-align:middle;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline"><span style="border:none;display:inline-block;overflow:hidden;width:137px;height:68px"><img src="https://lh7-us.googleusercontent.com/OubMXEaSzW6cz-Rt9RyUGsuX2z_G2pbaWOSLNAI_1YuZEk9lVaehxLoZgJt6AbxshlaXTZ4HHvQjpxPRVTWVxlwCl-fPKhGsbSTcgVVvejMX1rS_DaeeX4yOVQyvp2y3cFkC6XMBihqiTrDY3qBYwq8" width="137" height="68" style="margin-left:0px;margin-top:0px"></span></span></p></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Poppins,sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline"> Atul Tulshibagwale</span></p><p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Poppins,sans-serif;color:rgb(102,102,102);background-color:transparent;vertical-align:baseline"> CTO</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(136,136,136);background-color:transparent;vertical-align:baseline"> </span><a href="https://www.linkedin.com/in/tulshi/" target="_blank"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline"><span style="border:none;display:inline-block;overflow:hidden;width:24px;height:24px"><img src="https://lh7-us.googleusercontent.com/nf4RO594hvFNyujzHdKSn1RCJcOIC1-Mk2-_S2GLH4LUi6Prxj4bL0tyguJ-6XH50k_fHPq6nynNBdkJwAzgGdYlImXDDKv07yQuj5PcskVaBqf9vL1Z2esDwZsb5Z9J4tvDcPiiZdQSuyzywRbH3Fs" width="24" height="24" style="margin-left:0px;margin-top:0px"></span></span></a><a href="mailto:atul@sgnl.ai" target="_blank"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline"><span style="border:none;display:inline-block;overflow:hidden;width:24px;height:24px"><img src="https://lh7-us.googleusercontent.com/jy9xWqMUZyDKsa5W_-BxVILzsnbgKHSkJVzdCeCWVVSvhJbGal-I_Ja-qTTnA1SpYE65RrEcWMMLNPfbrp9HXjBOKdeXNIVuhOBg-vZe-Ed8e0rCV8BMjih-COWlyljD_Hfqg2SzCuqKASIsPk1O6_w" width="24" height="24" style="margin-left:0px;margin-top:0px"></span></span></a><a href="https://x.com/zirotrust" target="_blank"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline"><span style="border:none;display:inline-block;overflow:hidden;width:24px;height:24px"><img src="https://lh7-us.googleusercontent.com/N98NNhPOiQxQunuxKbv5L50QKM2TRayIDZDsOkFpZBpnxX7DATMDAj6a1zNXbjWfqluWTHt6BLNE9WbRSEYForDpaWWxtEd63NkpNqVY_9xAKyidyaSrYvOdHmKaijtXcPetATtR_eUKqs21wuYLq5w" width="24" height="24" style="margin-left:0px;margin-top:0px"></span></span></a></p></td></tr></tbody></table><br></div><div dir="ltr" style="margin-left:0pt" align="left"><h1 id="gmail-WG-Meeting-2024-12-03" style="box-sizing:border-box;margin:0px 0px 16px;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);max-width:100%;border-bottom:1px solid;padding-bottom:0.3em;letter-spacing:0.35px"><span style="box-sizing:border-box">WG Meeting: 2024-12-03</span></h1><h2 id="gmail-Agenda" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;max-width:100%;border-bottom:1px solid;padding-bottom:0.3em;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Agenda" title="Agenda" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><span style="box-sizing:border-box">Agenda</span></h2><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;max-width:100%;padding-left:2em;color:rgb(51,51,51);font-family:Inter,-apple-system,"system-ui","Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,system-ui,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;letter-spacing:0.35px"><li style="box-sizing:border-box"><a href="https://github.com/openid/sharedsignals/pull/205" target="_blank" rel="noopener" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none"><span style="box-sizing:border-box">Risk level change event</span></a></li><li style="box-sizing:border-box;padding-top:0.25em"><a href="https://github.com/openid/sharedsignals/issues/211" target="_blank" rel="noopener" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none"><span style="box-sizing:border-box">Permanence of streams</span></a></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Combine CAEP and CAEP Interop Profile specs?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Issues marked/labeed for v1Final</span></li></ul><h2 id="gmail-Attendees" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;max-width:100%;border-bottom:1px solid;padding-bottom:0.3em;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Attendees" title="Attendees" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><span style="box-sizing:border-box">Attendees</span></h2><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;max-width:100%;padding-left:2em;color:rgb(51,51,51);font-family:Inter,-apple-system,"system-ui","Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,system-ui,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;letter-spacing:0.35px"><li style="box-sizing:border-box"><span style="box-sizing:border-box">Atul Tulshibagwale (SGNL)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Sean O'Dell (Disney)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Yair Sarig (Omnissa)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Apoorva Deshpande (Okta)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Stan Bounev (VeriClouds)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Shayne Miel (Cisco)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Erik Gomez (JGSW)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Thomas Darimont (OIDF)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Brian Soby (AppOmni)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Tushar Raibhandare (Google)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Martin Gallo (Individual)</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">Jen Schreiber (Workday)</span></li></ul><h2 id="gmail-Notes" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;max-width:100%;border-bottom:1px solid;padding-bottom:0.3em;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Notes" title="Notes" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><span style="box-sizing:border-box">Notes</span></h2><h3 id="gmail-Risk-Level-Change" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;font-size:1.25em;max-width:100%;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Risk-Level-Change" title="Risk-Level-Change" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><a href="https://github.com/openid/sharedsignals/pull/205" target="_blank" rel="noopener" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none"><span style="box-sizing:border-box">Risk Level Change</span></a></h3><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;max-width:100%;padding-left:2em;color:rgb(51,51,51);font-family:Inter,-apple-system,"system-ui","Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,system-ui,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;letter-spacing:0.35px"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Stan) Does this event represent something different?</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Atul) I agree it is a separate event</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) I agree</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) I agree</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) Thumbs up</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) Does anyone have a concern that the levels won't mean the same and won't incorporate the same contributing factors in producing the same event</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Apoorva) This could be the same issue in device compliance change, assurance level change, etc. This is not different.</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) I agree it isn't new, but if the precedent isn't the right one, then should we continue this?</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Sean) In the absence of knowing what we don't know, not doing this doesn't make sense</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) We might get this wrong a few times, but we can improve it</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) But at a higher level, if there is a "capture-all" event, then it is difficult for that capture-all event to be consistent across the vendors</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Yair) If different vendors provide different reasons, then</span><span class="gmail-smartypants" style="box-sizing:border-box">…</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) For example, we provide threat intelligence, and this conversation always comes up, and customers are not sure what the "high", "medium", "low" means.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) This makes it difficult to adopt the specs</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) If we provide some way for customers to get alignment, then the adoption improves</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) Can we put some wording into what the "high", "medium" or "low" means.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) This is an event that is complementary to "assurance level" or "device compliance" change</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) I don't believe it is complementary. If someone sends this event, they don't need to send any device compliance / assurance level change events</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) We are not here to decide what is the "high", "medium" or "low" risk means.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) CAEP should allow more specialized and more general events, receivers can request the specific events they are capable / interested in.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) We should have definite meanings in terms of what "high", "medium" and "low" mean in terms of session security as asserted by the transmitter</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) Transmitters should send more specific events, rather than sending a high level "risk change" event</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) I don't feel we should prevent one way or the other</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Adam) Mastercard would like to inject fraud signals based on insights from ATO detection / Payment fraud events</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) Why is the risk reason required?</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Apoorva) Its to indicate to the receiver the rationale of the Transmitter in sending the event. It could become an enum specific to the Tx and Rx. So the localization may not be required.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) Why is it required?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) Without the reason, it won't make sense to the receiver</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) Most of the time, the risk level change is sufficient, the reason may not always be needed</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) I agree it should not be required</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) I can step it down to "recommended"</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) Sounds good</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) SG</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) The examples need updating</span></li></ul></li></ul><h3 id="gmail-Performance-of-Streams" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;font-size:1.25em;max-width:100%;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Performance-of-Streams" title="Performance-of-Streams" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><span style="box-sizing:border-box">Performance of Streams</span></h3><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;max-width:100%;padding-left:2em;color:rgb(51,51,51);font-family:Inter,-apple-system,"system-ui","Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,system-ui,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;letter-spacing:0.35px"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Tushar) When a Transmitter has created a stream and the receiver doesn't receive anything for a long duration. There is nothing required in the spec that the Transmitter or Receiver can use to determine when to expire the stream</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) This is captured in </span><a href="https://github.com/openid/sharedsignals/pull/222" target="_blank" rel="noopener" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none"><span style="box-sizing:border-box">PR #222</span></a></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) Were there other aspects to it?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) For a "poll" stream, if the Tx generates a large number of events, and the Receiver never polls, then the Tx has to hold a lot of data for the Rx</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) So there should be another way to indicate how many events / how much data the Tx has to hold</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) This is the same issue with polling</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) This could be specified in the stream configuration</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) I support the way Shayne suggested: Stream configuration rather than metadata configuration. Some streams may be more frequent than others</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Tushar) The TTL is independent of the optimization</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Brian) This is something I would want a negotiation - the requester could request something and the Transmitter can determine its own</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Stan) We need to also provide a way for the Tx to know that the Rx has expired the stream (and vice versa)</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Tushar) The spec already has a "stream updated" event, which can be used</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Brian) The receiver invalidating the stream is interesting. The status codes can be used, but some way to indicate the expiration from the receiver is interesting.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Shayne) The Tx can pause or disable the stream by sending a "stream updated" event.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Brian) But the Tx doesn't indicate why it is doing it</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Jen) The Tx doesn't need to justify</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) It's how much you want to hold for a specific receiver.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) This is about a stream that is dead. The Tx may be sending events to someone who doesn't care about it.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) I don't think you can automate stream deletion? If you use a status code, you can draw wrong conclusions. You need to have metadata about the receiver. There are too many variables</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) The original PR / issue was proposed to handle the authorization problem (Rx loses the token, but the streams are active), so if we are talking about this use case, then it's different.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) The TTL gives time for the Rx to fix the temporary issues. But if the Rx cannot recover in the TTL period, then the Tx can expire the stream.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) If you are offering a streaming service, how do you reconcile a lapse(?) An ack doesn't mean that the Rx has processed it.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Thomas) Does this mean that receivers have to periodically request a verification event to make sure that the transmitter can still send a push?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) Is the TTL inactivity or absolute?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) Inactivity</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) For the amount of data, does it need to be configured per stream? Can the Tx make a blanket statement across receivers?</span><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:0px;padding-left:2em"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(Atul) It needs to be per stream</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) But if the volume of events far exceeds the limit, then anyway they can't do anything about it. So is it even worth having it in the spec</span></li></ul></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Sean) Verifying a stream is a good way to keep a stream active. But an "ack" is also sufficient</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) I was saying in the context of inactivity</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Brian) Are we talking about "poll" or "push" too?</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) The way the PR is written,</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) The original discussion was about what happens if the stream live or not. Regardless of push or poll.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) That's why the Receiver needs to do something in order to indicate that it is using the stream.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) polling is different, because the Receiver is actually reaching out to you. But the push doesn't require the Rx to do anything.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) About the data, it's not just about polling. There needs to be a limit either way. There needs to be a way for the Tx or Rx to negotiate a limit. The way the spec says it, the Tx has some obligation to keep messages for a very long time</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) Might be a digress, but if the short lived stream is an objective, then can we just have an absolute expiry.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Yair) It's not about short-lived. It's about whether the Receiver still interested.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Apoorva) It's not about whether the Rx is interested, but whether they still have the token. If they had the token the Rx can delete the stream.</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Atul) It could be other reasons, like the Rx has gone down</span></li><li style="box-sizing:border-box;padding-top:0.25em"><span style="box-sizing:border-box">(Tushar) We could think of it as: Tx doesn't need to depend on a well-behaved Rx.</span></li></ul><h2 id="gmail-Action-Items" style="box-sizing:border-box;font-family:"Readex Pro",-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";line-height:1.25;color:rgb(51,51,51);margin-top:24px;margin-bottom:16px;max-width:100%;border-bottom:1px solid;padding-bottom:0.3em;letter-spacing:0.35px"><a class="gmail-anchor gmail-hidden-xs" href="#Action-Items" title="Action-Items" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none;float:left;line-height:1;padding-right:4px"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal" style="box-sizing:border-box;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;font-size:16px;line-height:1;font-family:octicons;display:inline-block;color:rgb(0,0,0);vertical-align:middle"></span></a><span style="box-sizing:border-box">Action Items</span></h2><ul style="box-sizing:border-box;margin-top:0px;max-width:100%;padding-left:2em;color:rgb(51,51,51);font-family:Inter,-apple-system,"system-ui","Segoe UI","Helvetica Neue",Helvetica,Roboto,Arial,system-ui,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;letter-spacing:0.35px;margin-bottom:0px"><li style="box-sizing:border-box"><span style="box-sizing:border-box">(All) Please review </span><a href="https://github.com/openid/sharedsignals/pull/222" target="_blank" rel="noopener" style="box-sizing:border-box;background-color:transparent;text-decoration-line:none"><span style="box-sizing:border-box">PR #222</span></a></li></ul></div></span></div></div></div>