Résumé

  • Dans draft-deshpande-secevent-http-multi-set-push-03, une même réponse 202 peut acquitter certains jti, en rejeter d’autres dans setErrs et citer des envois antérieurs. Le code HTTP concerne l’enveloppe, pas l’achèvement du lot.
  • Le texte est une soumission individuelle parrainée par un Area Director, en Last Call jusqu’au 23 septembre 2026. Il n’a ni état de groupe de travail, ni implémentation confirmée, ni approbation IESG, ni numéro de RFC, ni action IANA achevée.

Quatre Security Event Tokens partent dans une seule requête. Le serveur répond 202. Pour une supervision centrée sur les requêtes, l’histoire s’arrête là. Pour le protocole, elle commence à peine : trois identifiants peuvent figurer dans ack, un quatrième dans setErrs, et un identifiant transmis la veille peut être ajouté à la même réponse.

La révision 03 de HTTP Push Delivery of Multiple Security Event Tokens organise précisément cette dissociation. Elle réduit le coût des échanges sans transformer les SET en transaction. Le statut 202 signifie donc que l’enveloppe a été acceptée ; il ne constitue pas une preuve collective de résultat.

Le jti, unité de rapprochement

Le type application/secevents+json contient un objet sets indexé par le jti de chaque jeton. Le récepteur valide chaque membre séparément. Sa réponse 202 contient obligatoirement un tableau ack et peut ajouter un objet setErrs, lui aussi indexé par jti. L’exemple du projet réunit succès et erreur dans une seule réponse acceptée.

La temporalité n’est pas davantage enfermée dans la requête courante. Un récepteur peut renvoyer l’issue de SET antérieurs ; un émetteur peut envoyer un objet sets vide pour interroger les résultats différés. Un résultat portant sur un identifiant inconnu doit être ignoré. Pour réconcilier l’échange, il faut donc relier chaque résultat à son événement, et non au seul POST qui le transporte.

Un SET sans résultat est repris jusqu’à son acquittement, une erreur propre au SET ou la limite d’essais. Des règles locales de durée ou de stockage peuvent ensuite provoquer son abandon. Aucun de ces choix n’est visible dans le premier 202.

Livraison et effet métier restent distincts

L’acquittement du projet couvre réception, analyse et validation. Il ne certifie pas une révocation de session, une suspension de compte ou toute autre mesure en aval. RFC 8935 posait déjà cette séparation pour la livraison unitaire ; RFC 8417 décrit un SET comme une déclaration de fait, pas comme une commande.

RFC 9110 est tout aussi explicite : 202 indique une demande acceptée pour traitement, mais un traitement non achevé, qui pourrait ne jamais avoir lieu. Multi-SET Push ajoute des éléments par événement à l’intérieur de cette réponse volontairement non concluante. Il ne change pas le sens de HTTP.

Le lot n’établit pas non plus d’ordre. Chaque SET est indépendant, sa place dans l’objet ne crée aucune dépendance chronologique et le projet n’impose aucune transaction. Une relation causale doit être prouvée ailleurs que par la proximité de deux entrées JSON.

Un jalon de procédure soigneusement borné

Datatracker présente la révision 03 comme un Internet-Draft individuel actif dans la Security Area, visant Proposed Standard. La Last Call, ouverte le 26 août, se termine le 23 septembre. L’état de groupe de travail est None et aucune téléconférence IESG n’est prévue.

Le dossier de shepherd explique que SECEVENT était clos et que l’énergie manquait pour le reconstituer. Le texte avance donc comme soumission individuelle parrainée par Deb Cooley. Ce choix n’indique pas un conflit technique, mais il ne permet pas non plus de revendiquer un consensus de groupe.

La revue Security Directorate juge le texte prêt, avec une légère suggestion rédactionnelle. Le dossier ne confirme aucune implémentation ; l’intention de l’intégrer à OpenID Shared Signals Framework demeure un projet. Les actions IANA dépendent encore d’une approbation future.

Fabriquer un reçu par événement

Daniel Kade propose de conserver, pour chaque jti, l’identifiant et l’heure de la requête d’origine, l’acquittement ou l’erreur exacts, la référence éventuelle à un envoi antérieur, le compteur de reprises, la décision de nouvel essai et le motif d’abandon. Il faut y joindre la version de configuration du récepteur, l’heure de validation et l’état appliqué, rejeté ou en attente du système aval.

Ce reçu est un dispositif éditorial de gouvernance, non une exigence de l’IETF. Il autorise l’agrégation sans sacrifier la possibilité de remonter à chaque événement. Une case verte 202 prouve l’acceptation du transport ; sans la chaîne jti, elle ne dira jamais ce qui a réellement été validé, rejeté ou exécuté.

Sources