Resumen

  • draft-deshpande-secevent-http-multi-set-push-03 permite que una respuesta 202 confirme unos jti, rechace otros mediante setErrs e incluya resultados de solicitudes anteriores. El código acepta el sobre, no certifica el lote.
  • Es una presentación individual patrocinada por un Area Director, en Last Call hasta el 23 de septiembre de 2026. No tiene estado de grupo de trabajo, implementación confirmada, aprobación del IESG, RFC ni registro IANA completado.

Un emisor coloca cuatro Security Event Tokens en un POST. Recibe 202 y la métrica de solicitudes exitosas sube. Sin embargo, el cuerpo puede reconocer tres identificadores, devolver un error para el cuarto y resolver además un jti enviado en otro momento. Tampoco demuestra que el receptor haya aplicado una revocación o cualquier cambio de seguridad posterior.

La revisión 03 de HTTP Push Delivery of Multiple Security Event Tokens adopta esa separación de forma deliberada. Ofrece eficiencia de transporte, no atomicidad. Convertir 202 en «todo el lote terminó» borraría justamente la información que el nuevo formato aporta.

La contabilidad está en cada jti

application/secevents+json transporta un objeto sets cuyas claves son los jti. El receptor valida cada SET por separado. La respuesta 202 lleva un array obligatorio ack y puede añadir setErrs, un mapa de errores por identificador. El ejemplo normativo mezcla ambos resultados dentro de una respuesta aceptada.

El mensaje tampoco está atado al POST presente. Puede informar sobre tokens de solicitudes anteriores, y un emisor puede mandar sets vacío para consultar resultados diferidos. Un resultado para un identificador desconocido debe ignorarse. La unidad de conciliación es el evento identificado, no la llamada HTTP.

Un SET pendiente se reintenta hasta recibir confirmación, error específico o alcanzar el máximo de intentos. Límites locales de tiempo o almacenamiento pueden provocar su descarte. Esa política y su resultado deben registrarse: no se deducen del primer 202.

Confirmar entrega no confirma efecto

El acuse cubre recepción, análisis y validación. No garantiza una acción de negocio. RFC 8935 ya separa la entrega del procesamiento posterior, y RFC 8417 define un SET como una declaración de hecho, no una orden. La decisión del receptor pertenece a otra capa.

RFC 9110 refuerza el límite: 202 significa aceptado para procesamiento, todavía no completado, y el procesamiento podría no llegar a ocurrir. Multi-SET Push agrega resultados por elemento dentro de ese sobre, sin cambiar la semántica de HTTP.

Tampoco existe orden implícito. El borrador declara independientes los SET, niega dependencias cronológicas por posición y no impone transacciones. La vecindad en JSON no prueba causalidad ni secuencia operacional.

Qué significa realmente la Last Call

Datatracker muestra la revisión 03 como Internet-Draft individual activo en el área de Seguridad, con Proposed Standard como destino. La Last Call empezó el 26 de agosto y termina el 23 de septiembre; el estado de grupo de trabajo es None y no hay telechat programada.

El informe del shepherd dice que SECEVENT había concluido y que no existía energía suficiente para reconstituirlo. Por eso Deb Cooley patrocina la presentación individual. No es señal de controversia técnica, pero tampoco una adopción de grupo de trabajo.

La revisión del Security Directorate marca el texto como Ready con una corrección menor. No hay implementaciones confirmadas. La intención de incorporarlo a OpenID Shared Signals Framework no equivale a despliegue, e IANA actuaría sólo tras una eventual aprobación. La Last Call no es aprobación del IESG ni publicación como RFC.

Un comprobante que pueda auditarse

Daniel Kade propone conservar por cada jti la solicitud original y su hora, el acuse o error exacto, la correlación con respuestas tardías, el número de intentos, la próxima decisión y el motivo final de descarte. Deben añadirse versión de configuración del receptor, hora de validación y estado aplicado, rechazado o pendiente aguas abajo.

Es un diseño editorial de gobernanza, no un requisito del IETF. Permite resumir sin perder trazabilidad. El 202 verde acredita el sobre; sólo la cadena individual puede demostrar qué ocurrió con cada evento.

Fuentes