Resumen

  • La versión 03 de draft-deshpande-secevent-http-multi-set-push está en la última consulta del IESG hasta el 23 de septiembre de 2026. Es un Internet-Draft individual del área de Seguridad, destinado a Proposed Standard, no una norma aprobada.
  • Un POST HTTPS puede llevar varios Security Event Tokens (SET). La respuesta identifica mediante jti cuáles constan en ack y cuáles presentan errores setErrs; ese resultado cubre recepción y validación, no una actuación posterior.
  • La organización receptora debe poder distinguir la llegada del evento, su custodia, la decisión bajo su política y el efecto observado. El estado 202 del transporte no cierra esa cadena.

La economía de peticiones cambia la unidad de control

Un transmisor que envía un SET tras otro conoce el resultado de cada llamada, aunque tampoco puede deducir de ella qué hizo el destinatario. Al agruparlos, ni siquiera basta con mirar la llamada: una misma respuesta puede acusar algunos tokens y señalar errores en otros. Si un equipo de seguridad cuenta solicitudes aceptadas en lugar de eventos identificados, puede celebrar una mejora de rendimiento mientras una alerta urgente sigue esperando respuesta.

RFC 8935 ya regula la entrega de un único SET mediante POST sobre TLS. La propuesta multi-SET ataca la sobrecarga de hacer muchas peticiones al mismo receptor y la presión de los límites de velocidad. Coloca en sets pares formados por el jti y el token; el receptor devuelve una lista ack y, cuando procede, un objeto setErrs por token. El expediente del IETF seguía en IESG Last Call el 21 de septiembre. No acredita implementación, adopción comercial ni decisión final del IESG.

El detalle decisivo está en lo que significa acusar recibo. El borrador ordena incluir cada jti recibido en ack o setErrs; restringe los errores individuales a problemas de análisis y validación del SET. Una decisión empresarial posterior —por ejemplo, si la identidad externa corresponde a una cuenta local o si una sesión debe cerrarse— queda fuera de esa respuesta. Un 202 puede acompañar la aceptación del mensaje y el acuse de un token sin certificar la revocación de credenciales.

Ni siquiera hay una correspondencia obligatoria entre la respuesta y la petición actual. Un sets vacío permite solicitar acuses pendientes, y ack o setErrs pueden referirse a tokens de una transmisión anterior. La reconciliación por jti es indispensable. Tras un acuse, el transmisor ya no tiene que conservar el SET para retransmitirlo; el receptor asume la conservación que requiera su propia política de fiabilidad. Por tanto, una empresa que borra el rastro local después de responder puede quedarse sin la única prueba de qué recibió.

La ausencia de acuse requiere otro tratamiento. El transmisor debería reintentar un token que no aparezca ni en ack ni en setErrs dentro de un plazo razonable, aunque puede limitar los intentos. Una vez acusado o rechazado, no debe volver a transmitir el mismo jti; tras un error necesita un nuevo SET y un identificador nuevo. El receptor puede desechar silenciosamente duplicados ya tratados, pero el borrador no le obliga a implementar protección contra repetición. Estas reglas no ofrecen ejecución exactamente una vez.

La ganancia de ancho de banda tampoco autoriza esperar indefinidamente para llenar un lote. El texto prohíbe retrasos indebidos y recomienda enviar cuando se alcance un tamaño o transcurra un plazo desde el SET más antiguo; menciona uno o dos segundos como ejemplo. También propone límites tanto de cantidad como de bytes, y un rechazo completo con 413 si se superan. Cada SET es independiente: el orden dentro del JSON no fija una secuencia temporal ni crea una transacción en los sistemas receptores.

El asunto es distinto del de RFC 9967, que vincula una solicitud SCIM asíncrona con un evento posterior. Aquí se discute la entrega agrupada y su acuse individual. Ninguno de los dos instrumentos transfiere al emisor la autoridad para suspender una cuenta en otra organización.

Fuentes

Estado del borrador; versión 03; RFC 8935; RFC 8417; RFC 9967.