[Openid-specs-risc] Fwd: [saag] Requesting feedback on Push-Based Delivery For Multiple Security Event Token (SET) Using HTTP

[Atul Tulshibagwale]

FYI, my feedback on the Multi-SET push draft.

---------- Forwarded message ---------
From: Atul Tulshibagwale <atul at sgnl.ai>
Date: Fri, Sep 26, 2025 at 1:32 PM
Subject: Re: [saag] Requesting feedback on Push-Based Delivery For Multiple
Security Event Token (SET) Using HTTP
To: Apoorva Deshpande <apoorva.deshpande=40okta.com at dmarc.ietf.org>
Cc: <saag at ietf.org>, Aaron Parecki <aaron.parecki at okta.com>


Hi Apoorva and Aaron,
Thanks for sharing this draft. Here are my comments:

   - 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.
   - 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.

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.

Atul


On Mon, Sep 15, 2025 at 5:43 PM Apoorva Deshpande <apoorva.deshpande=
40okta.com at dmarc.ietf.org> wrote:

> Hello All,
>
> Aaron and I are requesting your feedback on the proposal, Push-Based
> Delivery For Multiple Security Event Token (SET) Using HTTP
> <https://datatracker.ietf.org/doc/draft-deshpande-secevent-http-multi-push/>.
> (This was part of the previously proposed push-pull
> <https://datatracker.ietf.org/doc/draft-tulshibagwale-saag-pushpull-delivery/> draft,
> which is now retracted)
>
> As stated in the draft, this work is incremental to RFC 8935
> <https://www.rfc-editor.org/rfc/rfc8935.html> and proposes an efficient
> transport.
>
> The following are some of the highlights of the proposal over the existing
> transport.
>
>    - 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 *multiple, distinct
>    subjects*. 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 *single subject* (via the sub claim or
>    sub_id claim from RFC 9493), to communicate events about multiple
>    subjects, you need multiple SETs.)
>    - 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.
>    - This draft introduces a mechanism for batching SETs for different
>    subjects into a single HTTP request, greatly improving transport
>    efficiency. It's *NOT* about changing the structure of a SET itself
>    but rather about how a collection of otherwise independent SETs is bundled
>    for delivery.
>    - 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 develop an interoperability profile
>    <https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html>for
>    this mechanism should the work be adopted.
>
>
> Thanks, looking forward to hearing the feedback
> _______________________________________________
> saag mailing list -- saag at ietf.org
> To unsubscribe send an email to saag-leave at ietf.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250926/567a2c72/attachment.htm>