Résumé

  • La version 03 de draft-deshpande-secevent-http-multi-set-push est un Internet-Draft individuel de la zone Sécurité, visé comme Proposed Standard. Son IESG Last Call se termine le 23 septembre 2026 ; aucune décision finale n’est acquise.
  • Un seul POST HTTPS peut contenir plusieurs Security Event Tokens. La réponse associe à chaque identifiant jti un ack ou une erreur setErrs, mais cet échange porte sur la réception et la validation du jeton, pas sur l’exécution d’une mesure de sécurité.
  • Pour savoir si un compte a réellement été suspendu, il faut suivre chaque événement au-delà du transport : conservation, correspondance d’identité, décision locale, application et constat du résultat.

La tentation du voyant vert

Dans un scénario hypothétique, une plate-forme expédie plusieurs alertes de compromission à un partenaire. Le serveur répond 202, accuse réception de certains jetons et signale qu’un autre ne passe pas la validation. Afficher « lot livré » serait commode pour le réseau, mais trompeur pour l’équipe chargée de couper un accès : la réponse ne dit pas si le compte local a été trouvé, encore moins si une session a pris fin. Aucun incident réel n’est allégué ici.

La proposition part d’un coût tangible. RFC 8935 définit déjà la livraison d’un seul SET par POST. Si des centaines d’événements attendent le même destinataire, multiplier les requêtes consomme de la capacité et peut rencontrer une limite de débit. Le nouveau texte place les jetons dans un objet JSON sets, indexé par leur jti, sous le type application/secevents+json. Le destinataire renvoie la liste ack et, pour les échecs propres à un jeton, l’objet setErrs. Au 21 septembre, le Datatracker indique « In Last Call » jusqu’au 23. Il s’agit d’une étape de discussion d’un projet, non d’un RFC publié ou d’une adoption observée.

Une réponse peut solder une autre requête

Le protocole proposé n’assimile pas « réponse HTTP » et « traitement du lot courant ». Un POST dont sets est vide peut demander les accusés de réception d’événements envoyés auparavant ; la réponse peut contenir des jti issus d’autres requêtes. Le rapprochement doit donc se faire jeton par jeton. Le texte exige que chaque SET reçu figure soit dans ack, soit dans setErrs, et réserve ce dernier canal aux problèmes d’analyse et de validation. Les erreurs de l’application qui décide d’une suspension ne relèvent pas de cet accusé de réception.

Après un ack, l’émetteur n’est plus tenu de garder le jeton pour une nouvelle transmission. Le destinataire porte la responsabilité de le conserver si sa propre fiabilité l’exige. Si un jeton n’apparaît dans aucune des deux catégories dans un délai raisonnable, l’émetteur devrait le retenter ; il peut fixer un plafond de tentatives. Une fois le jti accusé ou déclaré erroné, le même identifiant ne doit plus être envoyé. Après une erreur, une nouvelle émission impose un nouveau SET et un nouveau jti. La protection contre les répétitions reste facultative côté destinataire, qui peut ignorer silencieusement un duplicata déjà traité. Rien là ne constitue une garantie d’exécution « une fois exactement ».

Le regroupement a également un prix temporel. Le projet interdit de retarder indûment les événements dans le seul but d’agrandir un lot. Il recommande une émission dès que la taille choisie ou le délai du plus ancien jeton atteint son seuil ; une à deux secondes ne sont qu’un exemple. Le destinataire devrait plafonner à la fois le nombre de jetons et la taille totale en octets, puis rejeter un dépassement entier avec 413. Pour une alerte de révocation, l’âge du plus ancien événement compte davantage que l’économie moyenne de requêtes.

Enfin, l’ordre dans sets n’est pas un ordre d’exécution. Le projet traite chaque événement séparément et n’ajoute aucune transaction aux systèmes du destinataire. Une confirmation de transport n’atteste donc ni que deux mesures ont été appliquées ensemble ni qu’une première mesure a précédé la seconde. RFC 9967 décrit un autre problème : le lien entre une demande SCIM asynchrone et un événement ultérieur. Ce lien ne donne pas non plus à l’émetteur le pouvoir de décider ce que fera un domaine tiers.

Sources

État IETF ; texte de la version 03 ; RFC 8935 ; RFC 8417 ; RFC 9967.