摘要

  • draft-deshpande-secevent-http-multi-set-push-03 正处 IESG Last Call，截止日期为 2026 年 9 月 23 日。它是安全领域的个人互联网草案，目标为 Proposed Standard，尚非获批 RFC。
  • 草案把多个安全事件令牌放入同一次 HTTPS POST，以各自的 jti 在 ack 或 setErrs 中回应。回执针对接收、解析与验证，不能当成下游系统已完成停用或撤销的证明。
  • 运营者需要按事件追踪传输、持久保存、本地身份匹配、决策、执行和效果；批量请求的 202 状态码只覆盖其中一个边界。

一张绿色回执掩盖不了六种结果

设想一个机构向合作方一次发送六条账户安全事件。对方确认五条，报告一条令牌验证失败。若监控面板只显示“本次请求成功”，它既抹掉了第六条的错误，也把另外五条尚未完成的本地处置误写成结果。这是检验协议含义的假设场景，并非真实事故。

草案第 03 版提出的改进有明确对象。RFC 8935已经规定单个 Security Event Token（SET）经 HTTPS 推送；大量令牌若逐个发出，会增加请求开销，也可能碰到接收方速率限制。新草案使用 application/secevents+json，在 sets 对象中以令牌唯一标识 jti 为键，使接收方分别列出已确认的 ack 与验证失败的 setErrs。IETF Datatracker截至 9 月 21 日仍标记该稿处于 IESG Last Call；这是征求意见，不是最终批准，更不是部署记录。

确认的边界在令牌，不在账户

草案要求接收方将收到的每个 jti 列入确认或错误结果，并明确限制错误通道只报告令牌解析和验证问题。后续应用错误不能借这条回执报告。因此 HTTP 202 与 ack 的组合可以证明通信被接受、某个令牌经过相应检查，却不能证明另一机构识别了令牌所指的人，更不能证明会话已终止或凭据已撤销。接收方有自己的身份映射、政策与执行权。

回执的时间关系也不等于请求的时间关系。草案允许发送方提交空的 sets，催收先前批次尚未返回的结果；一个响应中的 jti 可以来自早前的 POST。运营系统必须按标识关联事件，而非按最后一次 HTTP 调用给整个批次贴状态。令牌获得确认后，发送方不必继续保留副本用于重传；接收方若需要可靠性保存，应承担相应保管责任。这一交接值得单独记账。

未收到确认则进入另一种状态。草案建议发送方在合理时间内重试既未出现在 ack 也未出现在 setErrs 的令牌，并允许限制尝试次数。已获确认或错误的相同 jti 不得再发送；错误后若要重发事件，必须制作带新标识的令牌。接收方的重放保护不是强制规定，它可以默默丢弃已经处理过的重复标识。由此不能从一次 POST 推断“恰好执行一次”。

批量效率还受时效约束。草案禁止为了凑大批次而无故拖延安全事件，建议达到数量门槛或最早令牌等待超过时间门槛时发送；一至两秒只是文中例子，不是普遍承诺。接收方应同时限制令牌数量和请求字节数，过大请求宜整体返回 413。共享一条传输通道也不赋予事务语义：草案明确说各 SET 相互独立、列表顺序不等于时间依赖，且不要求接收方的子系统按序处理。

这与 RFC 9967的 SCIM 异步请求及后来完成事件是两件事。前者涉及一个请求和后续事件如何关联；multi-SET 讨论多个令牌如何低成本送达并逐项回应。两者都不能替接收机构作出本地授权决定。没有一手资料证明本草案已经带来特定产品采用、账户停用结果或已完成的 IESG 决定。

来源

IETF 草案及当前状态；第 03 版原文；RFC 8935；RFC 8417；RFC 9967。