Summary

  • The IESG Last Call for draft-deshpande-secevent-http-multi-set-push-03 runs to 23 September 2026. The individual Security-area draft seeks Proposed Standard status; it is neither an approved RFC nor evidence of production adoption.
  • One HTTPS POST can carry multiple Security Event Tokens (SETs), with a response listing each token’s jti under ack or setErrs. An acknowledgement covers receipt and parsing or validation, not ordered processing or a completed downstream security action.
  • Operators relying on cross-domain feeds need separate evidence for transport, durable intake, local decision, enforcement and observed effect. Batch efficiency must not hide the oldest event’s wait time or make a 202 response look like proof of suspension or revocation.

One request, several unfinished stories

Imagine a transmitter sending six account-security events to a partner in one request. The partner acknowledges five token identifiers and reports a validation error for the sixth. An operations dashboard that marks the whole request “delivered” has collapsed six different outcomes into one green light. Even for the five acknowledged tokens, that light says nothing about whether the partner matched an account, disabled a session or rejected the event under its own policy. This is a hypothetical operating test, not a reported deployment.

The current draft proposes a transport answer to a real scaling problem. RFC 8935 already defines HTTPS push for one SET per request. When a sender has many events for the same recipient, repeating that request can consume capacity and collide with rate limits. The new application/secevents+json body places SETs in a sets object keyed by each token’s jti, allowing the receiver to respond with ack identifiers and individual setErrs. The Datatracker lists revision 03, dated 24 August, as an individual Security-area Internet-Draft in IESG Last Call through 23 September. Its intended status is Proposed Standard. That process record is not a final IESG decision.

What the acknowledgement owns

The distinction begins inside the response. A recipient must account for each received jti in ack or setErrs, and the draft confines per-event errors to SET parsing and validation. It explicitly bars using that acknowledgement channel to report later application errors. An HTTP 202 therefore records acceptance of the communication and bounded token disposition. It does not certify that a downstream identity system has suspended an account, revoked a credential or even accepted the token’s subject as one of its own users.

The response can also refer to an earlier request. An empty sets object lets a sender solicit acknowledgements that were deferred; the draft says an ack or setErrs entry need not correspond to the batch currently being posted. A batch dashboard must therefore reconcile by jti, not by the apparent success of the latest HTTP call. After acknowledgement the transmitter need not retain the SET for retransmission; the recipient becomes responsible for retention if its reliability requirements demand it. This handoff of custody makes a durable intake record important, but the draft does not define a downstream audit schema.

A missing response is its own state. The sender should retry a SET that appears in neither ack nor setErrs within a reasonable period, and it may cap attempts. Once it has received an acknowledgement or per-token error, it must not send the same jti again. A resend after a reported error requires a new token with a new identifier. The recipient’s replay protection is optional: it may silently discard a duplicate jti already handled. These rules prevent a simple “one POST equals one final event” accounting model. They do not make delivery exactly once or prove application exactly once.

Speed cannot be purchased with delay

The draft also limits the optimization it proposes. It says batching must not unduly delay security events and recommends flushing when a configured count is reached or a time threshold passes since the oldest SET was generated; one to two seconds is an example, not a universal service-level promise. It recommends caps on both number of tokens and body bytes, because a small count can still contain oversized tokens. A request over either limit should be rejected as a whole with HTTP 413. The transport bargain is thus bounded at both ends: too little batching raises request cost; too much can delay a compromise signal or exhaust the recipient.

No ordering or atomicity is conferred by sharing a request. The draft treats each SET as independent, says list order does not establish chronology and adds no transaction requirement on recipient subsystems. A password-reset event and a session-revocation event can arrive together without a guarantee that local systems will act in that order. Event time claims and local processing records are needed if sequence matters. The draft standardizes the delivery surface; the recipient retains the decision right and the burden of proving what happened after intake.

This is a different boundary from RFC 9967, whose SCIM event profile can correlate an asynchronous SCIM request with a later completion event. Neither that correlation nor a multi-SET ack transfers authority over another domain’s account. A recipient may need to reconcile identity, tenancy and policy before acting. The Last Call invites review of a proposed transport, not claims about observed deployment or a completed security result.

Sources

Current draft and IESG state; revision 03 text; RFC 8935 single-SET push; RFC 8417 SET format; RFC 9967 SCIM event profile.