<div dir="ltr">FYI, my feedback on the Multi-SET push draft.<br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Atul Tulshibagwale</strong> <span dir="auto"><<a href="mailto:atul@sgnl.ai">atul@sgnl.ai</a>></span><br>Date: Fri, Sep 26, 2025 at 1:32 PM<br>Subject: Re: [saag] Requesting feedback on Push-Based Delivery For Multiple Security Event Token (SET) Using HTTP<br>To: Apoorva Deshpande <apoorva.deshpande=<a href="mailto:40okta.com@dmarc.ietf.org">40okta.com@dmarc.ietf.org</a>><br>Cc:  <<a href="mailto:saag@ietf.org">saag@ietf.org</a>>, Aaron Parecki <<a href="mailto:aaron.parecki@okta.com">aaron.parecki@okta.com</a>><br></div><br><br><div dir="ltr">Hi Apoorva and Aaron,<div>Thanks for sharing this draft. Here are my comments:</div><div><ul><li>In Section 1, paragraph starting: "Push-Basd delivery for multiple SETs is intended to help in the following scenarios:", you should add another reason: The receiver wants to acknowledge or provide error responses to previously received SETs, but wants to do so asynchronously, not within the response to the same HTTP POST in which it received the SET.</li><li>The "sending zero SETs" is a good option in this spec. Should there be any guidance (non-normative) that a Transmitter should periodically send zero SETs if it has no SETs to send or retry sending, but it hasn't received acknowledgement for previously sent SETs? Right now section 5 only talks about retries. I can envision a case where a Transmitter is simply waiting for some time before it decides it needs to retry.</li></ul><div>This draft will be really valuable to the OpenID Shared Signals Working Group (SSWG) because right now SSF transmitters can only send one SET at a time using Push Delivery, and SSF Receivers need to either positively or negatively acknowledge those SETs synchronously within that HTTP call.</div></div><div><br></div><div>Atul</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 15, 2025 at 5:43 PM Apoorva Deshpande <apoorva.deshpande=<a href="mailto:40okta.com@dmarc.ietf.org" target="_blank">40okta.com@dmarc.ietf.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello All, </div><div><br></div><div>Aaron and I are requesting your feedback on the proposal, <a href="https://datatracker.ietf.org/doc/draft-deshpande-secevent-http-multi-push/" target="_blank">Push-Based Delivery For Multiple Security Event Token (SET) Using HTTP</a>. (This was part of the previously proposed <a href="https://datatracker.ietf.org/doc/draft-tulshibagwale-saag-pushpull-delivery/" target="_blank">push-pull</a> draft, which is now retracted)</div><div><br></div><div>As stated in the draft, this work is incremental to <a href="https://www.rfc-editor.org/rfc/rfc8935.html" target="_blank">RFC 8935</a> and proposes an efficient transport. <br><br>The following are some of the highlights of the proposal over the existing transport.</div><div><ul><li>RFC 8417 (SET) allows for multiple events within a single token, and existing standards define how to push them. The core motivation here is transport efficiency for use cases involving <b>multiple, distinct subjects</b>. In a high-volume environment, an event publisher often needs to transmit numerous events for different subjects to a subscriber in a short period. Under the current push mechanism (RFC 8935), this would necessitate a separate HTTP POST request for each subject's SET. This approach creates significant overhead and can be difficult to scale. (Note: RFC 8417 SET is bound to a <b>single subject</b> (via the <code>sub</code> claim or <font face="monospace">sub_id</font> claim from RFC 9493), to communicate events about multiple subjects, you need multiple SETs.) </li><li>The SSF specification also profiles SETs as a single event or multiple events that embody the single event information. Hence, bloating the SET to convey multiple events for multiple subjects in a single HTTP call is not possible.</li><li>This draft introduces a mechanism for batching SETs for different subjects into a single HTTP request, greatly improving transport efficiency. It's <b><i>NOT</i></b> about changing the structure of a SET itself but rather about how a collection of otherwise independent SETs is bundled for delivery.</li><li>We acknowledge that this introduces another transmission method. However, there's a precedent for having multiple, non-interoperable delivery mechanisms, such as the distinct poll-based (RFC 8936) and push-based (RFC 8935) methods. We believe the SSF working group, with its strong track record of successful interoperability events, is the perfect venue to <a href="https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html" target="_blank">develop an interoperability profile </a>for this mechanism should the work be adopted.</li></ul><br></div><div>Thanks, looking forward to hearing the feedback</div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(0,0,0);font-size:medium;font-family:Times"></div></div></div></div>
_______________________________________________<br>
saag mailing list -- <a href="mailto:saag@ietf.org" target="_blank">saag@ietf.org</a><br>
To unsubscribe send an email to <a href="mailto:saag-leave@ietf.org" target="_blank">saag-leave@ietf.org</a><br>
</blockquote></div>
</div></div>