Zusammenfassung

  • draft-deshpande-secevent-http-multi-set-push-03 befindet sich bis zum 23. September 2026 im IESG Last Call. Der individuelle Entwurf aus dem Sicherheitsbereich strebt den Status Proposed Standard an; ein verabschiedeter RFC ist er nicht.
  • Ein HTTPS-POST kann mehrere Security Event Tokens (SETs) enthalten. Für jede Kennung jti nennt die Antwort eine Bestätigung in ack oder einen Fehler in setErrs; beides betrifft Annahme und Validierung, nicht die anschließende Sicherheitsmaßnahme.
  • Wer organisationsübergreifende Meldungen nutzt, braucht für jedes Ereignis getrennte Nachweise über Eingang, Aufbewahrung, lokale Zuordnung, Entscheidung, Durchsetzung und beobachtete Wirkung.

Eine Antwort auf mehrere Geschichten

Nehmen wir einen erfundenen Fall: Ein Absender übermittelt sechs Ereignisse in einer Anfrage. Fünf Kennungen werden bestätigt, für die sechste meldet der Empfänger einen Validierungsfehler. Ein Monitoring, das nur den HTTP-Status 202 auswertet, würde das fehlerhafte Ereignis übersehen. Bei den fünf bestätigten bleibt zudem offen, ob das Zielsystem die betroffenen Konten überhaupt zuordnen und eine Sperre veranlassen konnte. Das ist ein gedanklicher Test, keine Meldung über einen Ausfall.

Der technische Anlass ist nachvollziehbar. RFC 8935 regelt den Push eines einzelnen SET per HTTPS. Bei vielen Meldungen an denselben Empfänger entstehen entsprechend viele Anfragen und möglicherweise Probleme mit Ratenbegrenzungen. Der neue Entwurf sieht deshalb einen JSON-Körper sets vor, der jeden Token über seinen jti adressiert; die Antwort führt bestätigte Kennungen unter ack und tokenbezogene Fehler unter setErrs. Laut Datatracker läuft der Last Call noch. Daraus lassen sich weder eine endgültige IESG-Entscheidung noch die Einführung in einem Produkt oder eine beobachtete Kontosperrung ableiten.

Die Grenze der Quittung ist ausdrücklich gesetzt. Der Empfänger soll jede erhaltene Kennung in einer der beiden Kategorien zurückmelden. Der Fehlerkanal für einzelne SETs ist auf Parsing und Validierung begrenzt; spätere Anwendungsfehler gehören nicht hinein. Eine erfolgreich geprüfte Meldung muss im fremden System erst einer Identität zugeordnet und nach dessen Regeln bewertet werden. TLS und HTTP-Status schützen beziehungsweise beschreiben die Übertragung, sie verleihen dem Absender keine Entscheidungsbefugnis über das Zielkonto.

Hinzu kommt die zeitliche Entkopplung. Ein POST mit leerem sets kann noch ausstehende Bestätigungen früherer Sendungen abfragen. In einer Antwort dürfen jti stehen, die nicht zum gerade gesendeten Bündel gehören. Die Buchführung muss deshalb an der Ereigniskennung ansetzen. Nach einer Bestätigung braucht der Absender den SET nicht länger für eine erneute Sendung aufzubewahren; der Empfänger ist für die nach seinen Zuverlässigkeitsanforderungen nötige Speicherung zuständig. Ohne dauerhaften lokalen Eingangsnachweis lässt sich dieser Übergang später schwer prüfen.

Für einen SET ohne ack und ohne setErrs wird eine Wiederholung nach angemessener Zeit empfohlen; der Absender darf die Anzahl begrenzen. Nach Bestätigung oder Fehlermeldung darf derselbe jti nicht erneut gesendet werden. Nach einem Fehler verlangt ein weiterer Versuch einen neuen SET mit neuer Kennung. Schutz vor Wiederholung ist auf Empfängerseite nicht vorgeschrieben; bereits bearbeitete Duplikate dürfen still verworfen werden. Eine Garantie für genau einmalige lokale Ausführung entsteht dadurch nicht.

Auch das Warten auf ein möglichst großes Bündel hat Grenzen. Der Entwurf untersagt unangemessene Verzögerung sicherheitsrelevanter Ereignisse und empfiehlt, bei Erreichen einer Anzahl oder einer Wartezeit des ältesten SET zu senden; ein bis zwei Sekunden sind ein Beispiel, keine allgemeine Zusage. Anzahl und Gesamtgröße in Byte sollen begrenzt werden, überschrittene Anfragen als Ganzes mit 413 zurückgewiesen. Die Reihenfolge der Einträge begründet weder Chronologie noch Transaktionspflicht für nachgelagerte Systeme.

RFC 9967 behandelt die Verbindung zwischen einem asynchronen SCIM-Auftrag und einem späteren Ereignis. Der Multi-SET-Entwurf behandelt dagegen die gebündelte Übermittlung. Beide lassen die lokale Entscheidung des Empfängers unberührt.

Quellen

IETF-Dokumentstatus; Entwurf Version 03; RFC 8935; RFC 8417; RFC 9967.