Zusammenfassung

  • Nach draft-deshpande-secevent-http-multi-set-push-03 kann eine 202-Antwort einige jti bestätigen, andere unter setErrs ablehnen und Ergebnisse älterer Anfragen enthalten. Der Status gilt für den Umschlag, nicht für den Abschluss aller Ereignisse.
  • Das Dokument ist eine vom Area Director geförderte Individual Submission im Last Call bis 23. September 2026. Es hat keinen Working-Group-Status, keine bestätigte Implementierung, keine IESG-Genehmigung, keine RFC-Nummer und keine abgeschlossene IANA-Registrierung.

Vier Security Event Tokens werden gemeinsam gesendet. Der Empfänger antwortet mit 202. In der Antwort stehen jedoch drei Kennungen unter ack, eine vierte unter setErrs und vielleicht eine fünfte aus einer früheren Anfrage. Ob ein bestätigtes Ereignis später eine Sitzung beendet oder einen Kontostatus ändert, bleibt davon unberührt.

Revision 03 von HTTP Push Delivery of Multiple Security Event Tokens macht diese Trennung zum Grundprinzip. Batching spart Übertragungsaufwand, erzeugt aber keine Transaktion. Ein grüner HTTP-Status darf deshalb nicht zum Abschlussbeleg für den ganzen Batch werden.

Abgerechnet wird pro jti

application/secevents+json enthält ein Objekt sets, dessen Schlüssel die jti der Tokens sind. Der Empfänger prüft jeden SET einzeln. Die 202-Antwort führt ein verpflichtendes ack-Array und optional setErrs als Fehlerabbildung pro Kennung. Das Beispiel des Entwurfs mischt Bestätigungen und Fehler in derselben angenommenen Antwort.

Auch die Zeitgrenze der aktuellen Anfrage ist durchlässig. Antworten dürfen ältere SET betreffen; eine leere sets-Abfrage kann verzögerte Ergebnisse abrufen. Meldungen zu unbekannten Kennungen sind zu ignorieren. Der Prüfpfad folgt somit dem Ereignis und nicht nur dem POST.

Ein offener SET wird wiederholt, bis Bestätigung, SET-spezifischer Fehler oder Versuchslimit erreicht sind. Lokale Zeit- und Speicherregeln können zur Verwerfung führen. Diese Entscheidungen lassen sich aus der ersten 202-Zeile nicht ableiten.

Empfang ist nicht Wirkung

Die Bestätigung deckt Empfang, Parsing und Validierung ab, nicht die spätere Fachaktion. RFC 8935 trennt Zustellung von weiterer Verarbeitung; RFC 8417 behandelt einen SET als Tatsachenaussage und nicht als Befehl.

RFC 9110 beschreibt 202 als zur Verarbeitung angenommen, aber noch nicht abgeschlossen; die Verarbeitung könnte ausbleiben. Multi-SET Push ergänzt dazu Einzelergebnisse, ohne die HTTP-Semantik umzudeuten.

Der Batch garantiert auch keine Reihenfolge. Jeder SET ist unabhängig, seine Position schafft keine chronologische Abhängigkeit, und der Entwurf verlangt keine Transaktion. Kausalität muss außerhalb der JSON-Nachbarschaft belegt werden.

Der begrenzte Stand im IETF-Prozess

Datatracker führt Revision 03 als aktiven individuellen Internet-Draft der Security Area mit Ziel Proposed Standard. Der Last Call läuft vom 26. August bis 23. September. Working-Group-Status ist None; ein Telechat ist nicht angesetzt.

Laut Shepherd war SECEVENT beendet, und für eine Neugründung fehlte genügend Energie. Deshalb läuft das Dokument unter Deb Cooley als AD-sponsored individual submission. Das ist kein Nachweis technischer Ablehnung, aber ebenso wenig ein Working-Group-Konsens.

Die Security-Directorate-Prüfung lautet Ready mit einem kleinen Textvorschlag. Bestätigte Implementierungen fehlen; die geplante Aufnahme in OpenID Shared Signals Framework ist noch kein Einsatznachweis. IANA-Schritte bleiben von einer künftigen Genehmigung abhängig.

Ein belastbarer Ereignisbeleg

Daniel Kade schlägt vor, pro jti ursprüngliche Anfrage und Zeit, genaue Bestätigung oder Fehler, Bezug zu älteren Anfragen, Versuche, nächste Entscheidung und Verwerfungsgrund zu speichern. Hinzu kommen Empfängerkonfiguration, Validierungszeit sowie angewandter, abgelehnter oder offener Status im nachgelagerten System.

Das ist ein redaktionelles Governance-Modell, keine IETF-Vorgabe. Es erlaubt Aggregation, ohne den Einzelnachweis zu verlieren. 202 belegt den angenommenen Umschlag; nur die jti-Kette belegt den weiteren Verlauf.

Quellen