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

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 -- [email protected]
To unsubscribe send an email to [email protected]