Zusammenfassung

  • Der individuelle Internet-Draft AAuth Events vom 28. September 2026 beschreibt, wie eine Ressource ein signiertes asynchrones Ereignis an den ständig erreichbaren Agent Provider (AP) eines abonnierten Agenten sendet.
  • Der AP darf 202 Accepted erst nach dauerhafter Aufzeichnung des angenommenen Ereignisses zurückgeben. Diese Quittung belegt weder die Zustellung an den Agenten noch Prüfung oder Handlung vor Ablauf des Ereignistokens.

Nach einem verpassten Ereignis sucht ein Betreiber nach dem ersten zuverlässigen Zeitstempel. Im Log der Ressource steht HTTP 202; beim AP liegt ein dauerhaft gespeicherter Datensatz. Die Versuchung ist groß, den Fall damit als „Agent benachrichtigt“ abzuschließen. Genau hier beginnt aber die Beweislücke. Der AP ist ein Zwischenempfänger. Sein Eingangsstempel erklärt noch nicht, wann der Agent das Ereignis bekam, ob er es akzeptierte und ob seine Handlungsfrist zu diesem Zeitpunkt noch offen war.

Dick Hardts AAuth Events ist ein erster individueller Internet-Draft mit der Versionsnummer -00, datiert auf den 28. September 2026. Der angegebene Zielpfad Standards Track ist eine Absicht, keine bereits erreichte Anerkennung. Der IETF Datatracker dokumentiert die Existenz des Entwurfs; er belegt weder einen verabschiedeten RFC noch den störungsfreien Betrieb einer Implementierung. Das Dokument ergänzt einen separaten AAuth-Protokollentwurf. Während dieser die Autorisierung eines Agenten bei einer Ressource behandelt, geht es nun um eine Nachricht, die nach der ursprünglichen Interaktion eintrifft.

Der Agent kann Ereignisse einer Ressource abonnieren. Die Ressource erstellt bei einem Ereignis ein signiertes Token und einen dazugehörigen Nachrichtentext und liefert beides an den AP. Dieser prüft die Signatur der Ressource, die vorgesehene Empfängeradresse im Token, das noch aktive Abonnement und den Abgleich des Textes mit body_s256. Die Kombination aus Aussteller und Ereigniskennung kann zum Erkennen von Dubletten dienen. Dadurch lässt sich eine unberechtigte oder veränderte Einsendung am ersten Übergang abweisen. Die Prüfungen ersetzen aber nicht die Feststellung, dass die eigentliche Agenteninstanz erreichbar war.

Der Entwurf zieht für die Annahme eine klare Linie. Vor der Antwort 202 muss der AP das angenommene Ereignis zur späteren Zustellung dauerhaft aufgezeichnet haben. Ein bloß empfangenes Paket in einem flüchtigen Puffer reicht nicht. Für den Betreiber ist das ein echter Nachweis über die Obhut des AP und damit mehr als ein unverbindlicher Netzwerkstatus. Der Beweis gilt jedoch nur für Ressource zu AP. Wie der AP an den Agenten ausliefert, ist plattformabhängig und ausdrücklich nicht Gegenstand des Entwurfs. Es gibt hier kein einheitliches Zustellprotokoll, keine standardisierte Agentenquittung, keine festgelegte Wiederholungsfolge und keine Ende-zu-Ende-Zusage.

Bei der nachträglichen Prüfung muss zudem die Uhr mitgelesen werden. Das Ereignis-JWT läuft ab. Der Agent muss nach Erhalt Gültigkeit, Publikum, Nachrichten-Hash und lokalen Zusammenhang prüfen. Ist das Token abgelaufen oder stimmt der Text nicht, darf er daraufhin nicht handeln. Man kann sich eine kurze Freigabe für einen verfügbaren Termin vorstellen, während der Agent offline bleibt. Der AP nimmt das Ereignis rechtmäßig an, speichert es und liefert es später unversehrt aus. Wenn die Frist dann vorbei ist, war die Aufbewahrung korrekt und die Benachrichtigung für die Entscheidung dennoch zu spät.

Dies ist ein Prüfszenario, kein Bericht über einen realen Vorfall.

Der Hash begrenzt eine andere Gefahr als die Verzögerung. body_s256 kann erkennen lassen, ob der AP den Inhalt verändert oder ausgetauscht hat. Laut Entwurf verhindert er nicht, dass der AP ein Ereignis zurückhält oder spät weitergibt. Auch ohne böse Absicht können Warteschlangen, fehlgeschlagene Weckversuche oder ein offline bleibender Agent denselben Effekt erzeugen. Ein unverfälschter Inhalt sagt nichts über die Dauer des Transports. Eine erfolgreiche Auslieferung sagt wiederum nichts darüber, ob der Agent den lokalen Kontext passend fand oder eine Aktion tatsächlich ausführte. Für eine Untersuchung gehören diese Zustände in getrennte Spalten, nicht unter ein einziges Häkchen.

Mit der Rolle des Postfachs erhält der AP auch zusätzliche Sicht. Er sieht, bei welchen Ressourcen seine Agenten Abonnements unterhalten, und er sieht die Ereignisinhalte. Der Entwurf benennt selbst den Unterschied zum Ziel des übergeordneten AAuth-Protokolls, die Ressourcennutzung einer Person nicht ohne Weiteres beim AP offenzulegen. Das ist kein Beleg, dass ein bestimmter Dienst diese Informationen missbraucht. Es ist eine Eigenschaft der vorgeschlagenen Architektur, die bei Einführung bewertet werden muss. Datenminimierung des Ereignistextes, Zugriff auf Abonnementinformationen und Aufbewahrungsfristen sind konkrete Entscheidungen, die die 202-Regel nicht automatisch trifft.

Wer nach einem Ausfall nur den ersten Eingangsstempel vorlegt, beantwortet die falsche Frage. Der Entwurf verbessert die Nachweisbarkeit der ersten Obhut, lässt die letzte Zustellung aber bei der Plattform. Die maßgebliche Prüfung lautet: Was kann der Betreiber für den Übergang zum Agenten vor dem Ablauf belegen, und welche Informationen wurden dafür beim AP konzentriert? Aus der Standards-Track-Absicht oder einer gültigen Signatur lässt sich die fehlende Antwort nicht ableiten.

Quellen