[saag] Re: Requesting feedback on Push-Based Delivery For Mu ltiple Security Event Token (SET) Using HTTP

Hi Apoorva, Aaron,

Below are my comments, in IETF-comments format.

Thanks,

      Yaron

# Review: draft-deshpande-secevent-http-multi-set-push-00

Acting individually, but as a former SecEvent co-chair, below are my comments. In general I think this is useful work which makes total sense as an extension to the existing SecEvent protocols.

## Comments

### Title

Token -> Tokens

### General

The document requires quite a bit of copyediting. Let ChatGPT have a go at it!

### Buffer Size

The Intro mentions that "possible implementation constraints such as buffer size limitations between the transmitter and recipient is out of scope." I think this needs to be explained. Buffer size constraints/negotiation is very common, why is it not needed in this case? Even if RFC 8935 did not do that, it's clearly more relevant for the batch use case than for the single-SET case.

A hardcoded limit of 20 SETs is mentioned below, IMO that's a good justification but then please mention it earlier.

### SET Delivery Semantics

This section is very confusing. It seems to discuss receipt and acknowledgement of individual SETs, one by one; on the other hand, the SETs are delivered as part of a JSON document which makes individual receipt hard or impossible, depending on the JSON implementation.

There are some streaming JSON implementations out there, but I'm wondering if instead of one big JSON document, it wouldn't be better to deliver many separate JSON documents, one for each SET, and then use HTTP chunking or even HTTP SSE underneath it for efficient and more reliable delivery.

Again, once the hardcoded-20 limit comes into consideration, these questions largely go away.

### Transmitting SETs

"The following is a non-normative example of a response." This should be "request."

### Sets Field

The `sets` member is marked as Optional but then the second example sends it as an empty object. If that's the preferred way, better make it Mandatory.

### Media Type

You are using a simple `application/json`, and I'm not sure that's ideal. The SET spec does not go for a simple `application/jwt`. Maybe `applications/secevent-batch+json`?

### Empty "ack"

Is there a semantic difference between a non-existent `ack` and one that contains an empty array?

### Response: High Level

I think there's too much optionality. Specifically, `err` should be Mandatory.

It's also not ideal to include two objects with the same type of key, where the Recipient needs to ensure there is no intersection and that all received SETs are included. It may be cleaner to turn the structure inside-out into one object indexed by `jti` where there's either an `ack` (possibly signaled by a `null`) or a `setErr` for each SET.

Since `description` is optional (as it should be IMO), there's no need to make Content-Language a MUST.

### Failure Response

Please consider using RFC 7807, "problem details". And again, the `err` field should be mandatory. Also, `many_sets` -> `too_many_sets`.

### 7.1 section title

Replace "response" by "request." And by the way this is symmetric: Transmitters also need to protect themselves against responses that are too large.

### IANA Considerations

Arguably "Failure Response” errors should be its own registry, if you want interoperability between Transmitters and Receivers.

From: Apoorva Deshpande <[email protected]>
Date: Tuesday, 16 September 2025 at 3:43
To: [email protected] <[email protected]>, Aaron Parecki <[email protected]>
Subject: [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 . (This was part of the previously proposed push-pull draft, which is now retracted)

As stated in the draft, this work is incremental to RFC 8935 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 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]