Zusammenfassung

  • Der IETF Datatracker führt den AUDIT-BoF-Antrag als Declined. Die am 31. August 2026 eingerichtete non-WG-Liste dient der Arbeit an einem möglichen neuen BoF und Charter, begründet aber keine Arbeitsgruppe.
  • Das IESG hielt die Auditierbarkeit von Agentenhandlungen für ein sinnvolles Anliegen, den vorgelegten Umfang jedoch für zu breit. Verlangt wurden eine schärfere Abgrenzung und eine Lückenanalyse zu OAuth, WIMSE, OpenTelemetry und benachbarten Arbeiten.
  • Der individuelle Architekturentwurf trennt Interaktions-, Aktions-, Delegations- und Autorisierungsübergangsdatensätze. Aufzeichnungsverweigerung, umfassende Kollusion, Modell-Alignment und ein detailliertes Bedrohungsmodell bleiben offen.
  • Ein öffentlicher Authority-State-Beleg sollte Diskussionsort, BoF-Entscheidung, Charter, Dokumentannahme, IETF-Prüfung, RFC-Veröffentlichung und Betrieb als getrennte Zustände erhalten.

Ein neuer Ort ändert den alten Beschluss nicht

Die IETF Secretariat kündigte die AUDIT-Liste am 31. August an. Der Schritt ist konstruktiv. Die Beteiligten können nun an einem engeren Problem, an Überschneidungen und an einem belastbareren Charter-Entwurf arbeiten. Er ist aber keine nachträgliche Genehmigung des vorherigen Antrags.

Der AUDIT-BoF-Antrag in Version 02 trägt weiterhin Typ und Status „Declined BOF request“ beziehungsweise „Declined“. Auch die Übersicht der BoF requests ordnet ihn so ein. Die letzte Aktualisierung datiert vom 6. Juli; verantwortliche Leitung ist nicht eingetragen. Im Antrag genannte Security Area Directors und der vorgeschlagene Chair Yaroslav Rosomakho bleiben Vorschläge, keine bestellten Amtsträger.

Die neue Liste beschreibt ihren Auftrag präzise. Im Verzeichnis der non-WG lists dient sie der Diskussion eines potenziellen AUDIT-BoF, der Überarbeitung eines vorgeschlagenen Charters und dem Ziel, eine neue WG zu bilden. Zum Stichtag enthält das öffentliche Listenarchiv nur die Gründungsankündigung. Die Grammatik verweist auf einen möglichen künftigen Zustand, nicht auf eine verdeckte Gegenwartsentscheidung.

Die Richtlinien für non-WG mailing lists sehen Listen vor, die auf die Bildung einer WG zielen. Der zuständige Area Director genehmigt die Einrichtung. Diese Genehmigung gilt dem Kommunikationskanal. Sie umfasst weder BoF noch Charter, Meilensteine oder Chairs.

RFC 2418 zeigt, wodurch sich eine Arbeitsgruppe auszeichnet: ein enges Charter, verantwortliche Area Directors, eingesetzte Chairs und definierte Verfahren. Eine WG benötigt eine Mailingliste. Daraus folgt nicht, dass jede Mailingliste eine WG ist. Infrastruktur kann ein Mandat ermöglichen, aber nicht ersetzen.

Die Entscheidungsgeschichte braucht beide Begriffe

In der IESG-Rückmeldung vom 3. Juni stand „deferred“. Erhalten ist sie in der Antwort der Antragsteller vom 5. Juni. Die Rückmeldung verwarf das Problem nicht. Sie bezeichnete das Auditieren von Agentenhandlungen als gutes Konzept, hielt den Umfang aber für zu weit. Der Vorschlag solle enger werden, OAuth und WIMSE einbeziehen und erklären, warum vorhandene Arbeiten oder ein OpenTelemetry-Profil die Lücke nicht schließen. Einige Vorstellungen von Absicht und Policy könnten eher in einen Rechtsrahmen als in eine IETF-Architektur gehören.

Die Antragsteller hinterfragten Ablauf und Bedeutung der Zurückstellung, verteidigten den Bedarf an domänenübergreifenden Beweisen und führten die Debatte über den Umfang fort. Damit liegt eine substantielle Kontroverse vor, die einen neuen Antrag verbessern kann. Eine förmliche Zustimmung entstand daraus nicht.

„Deferred“ bezeichnet folglich die Wortwahl der Juni-Kommunikation, „Declined“ den aktuellen Datatracker-Zustand. Ein zuverlässiger Beleg bewahrt beides mit Datum, Quelle und zuständigem Akteur. Ein späterer Antrag kann einen neuen Zustand schaffen, ohne die damalige Entscheidung umzudeuten. Aktuelle Ablehnung bedeutet nicht ewiges Verbot.

Das Problem entspricht Heng Lus Analyse der Multistakeholder-Mirage: Teilnahme und Anwesenheit liefern noch keinen Prinzipal und keine Vertretungsvollmacht. Eine IETF-Liste beweist Zugang zu einer Debatte. Sie beweist nicht, dass die Teilnehmenden für eine AUDIT-WG oder die IETF sprechen dürfen.

Vier Belegarten statt eines allwissenden Logs

Der individuelle AUDIT-Architekturentwurf vom 18. Mai nimmt ein ernstes Problem auf. Ein Mensch weist einen Agenten an; dieser delegiert, ruft Dienste in verschiedenen Verwaltungsdomänen auf, erhält zusätzliche Befugnisse und löst eine Wirkung aus. Lokale Logs können jeweils stimmen und dennoch keine gemeinsame Geschichte von Absicht, delegierter Autorität, Ausführung und Berechtigungswechsel liefern.

Der Entwurf definiert vier Familien. Interaction Records halten nutzerseitige Aufforderungen, Antworten und Freigaben als Absichtsevidence fest. Action Records dokumentieren das Ereignis an der Ausführungsgrenze. Delegation Records beschreiben übertragene Autorität, Umfang und Beschränkungen. Authorization Transition Records erfassen Erstgewährung, Step-up, Verengung, Widerruf und Ablauf.

Ein gemeinsamer Audit-Kontext könnte Korrelationskennungen und Verweise auf frühere Ereignisse tragen. Die beteiligten Akteure erzeugen Aufzeichnungen aus ihrer jeweiligen Sicht; ein teilweise vertrauenswürdiger Audit Store normalisiert sie. Attestation und Transparenzdienste können einzelne Belege zusätzlich absichern. Der Nutzen liegt in der Trennung: Eine geäußerte Absicht ist nicht dasselbe wie eine Befugnis, und eine Befugnis nicht dasselbe wie ein ausgeführter Vorgang.

Der Text nennt auch seine Nichtlösungen. Er setzt keinen vertrauenswürdigen Agenten voraus und vertraut dem Store nur teilweise. Er löst nicht, dass ein Dienst die Aufzeichnung an seiner Grenze verweigert, alle Rollen kolludieren oder das zugrunde liegende Modell fehlgeleitet ist. Eine detaillierte Sicherheits- und Bedrohungsanalyse bleibt Zukunftsarbeit. Korrekt signierte Datensätze können deshalb zugleich echt und unvollständig sein.

Der Datenschutzkonflikt ist grundlegend. Interaktionen können Prompts, Ziele und persönliche Daten enthalten; Aktionen offenbaren Werkzeuge und Geschäftsbeziehungen; eine globale Kennung kann eine Person über Organisationen hinweg verfolgen. Selbst ein bloßer Hash in einem Transparenzdienst verrät das Vorhandensein einer Interaktion zu einem Zeitpunkt. Vollständigkeit ist kein kostenloses Gut.

Der individuelle Entwurf zu verifizierbaren Agentengesprächen könnte ein Format für nutzernahe Nachweise liefern. Er ist kein von AUDIT angenommener WG-Entwurf, denn eine solche WG gibt es nicht. Eine signierte Unterhaltung beantwortet zudem nicht Minimierung, Schwärzung, selektive Offenlegung, Aufbewahrung und sichere Bindung an spätere Handlungen.

Benachbarte Standards begrenzen die Aussage

Die Überschneidungsanalyse ist ein technischer Auftrag, keine Formalie.

RFC 8693 über OAuth Token Exchange kann Delegationssemantik und Akteursketten bei Tokenaustausch darstellen. Das ist für übertragene Autorität relevant, bildet aber nicht die ursprüngliche Nutzeranweisung, alle späteren Übergänge, das Ergebnis und das Urteil des Auditors ab. Detaillierte Token-Semantik, Sicherheitseigenschaften und Vertrauensmodelle liegen außerhalb des Basisprotokolls.

Der W3C Trace Context verteilt Kennungen, die Abschnitte einer verteilten Anfrage verbinden. Eine Trace-ID erklärt Korrelation, nicht Berechtigung. Sie zeigt weder eine verengte Delegation noch Nutzerfreigabe oder Korrektheit. Ein technischer Zusammenhang ist keine Autorisierungskette.

RFC 9334 zur RATS-Architektur ordnet Evidence, Verifier, Attestation Results und die Policy-Entscheidung einer Relying Party. Damit lassen sich Komponenten oder Umgebungen bewerten. Rechtliche Autorität oder semantische Treue zum menschlichen Willen folgen daraus nicht. Ein intaktes System kann eine unzulässige Handlung tadellos ausführen.

RFC 9943 zur SCITT-Architektur beschreibt signierte Aussagen, append-only Transparenzdienste und Registrierungs- oder Inklusionsbelege. Nachträgliche Löschung und Veränderung werden sichtbarer. Wahrheitsgehalt, Vollständigkeit und Erlaubnis entstehen dadurch nicht. Kryptografische Integrität schützt die Bindung eines Claims, nicht seine gesamte Bedeutung.

Ein enger AUDIT-Entwurf muss deshalb ausweisen, was OAuth, WIMSE, Observability, RATS, SCITT und HTTP-Arbeiten besitzen und welche domänenübergreifende Naht übrig bleibt. Die Zahl benannter Akronyme ersetzt diese Zuordnung nicht.

Der Normungsprozess braucht seinen eigenen Authority State

AUDIT will rekonstruieren, wer eine Agentenhandlung autorisiert hat. Die IETF sollte ebenso rekonstruierbar machen, wer die jeweilige Normungsstufe autorisiert hat. In beiden Fällen darf ein Beleg für Aktivität nicht als Beleg für Vollmacht dienen.

Ein öffentlicher Receipt würde Problemidentität und exakte Vorschlagsversion führen. Der Zustand könnte proposal, deferred/declined BoF, non-WG discussion, approved BoF, chartering, active WG oder concluded lauten. Dazu gehören der zuständige Entscheidungsträger, Datum, Originalquelle und genaue Disposition.

Jede Fassung müsste das Scope-Delta nennen: Was wurde entfernt, was bleibt bei Nachbargruppen, was bleibt ungelöst? ADs und Chairs heißen bis zur Bestellung „proposed“. Venue und Authority sind getrennte Felder. Ein Charter hat eine genehmigte Revision und Datum oder ist null. Dokumente werden als individual oder WG-adopted bezeichnet und mit dem Adoptionsakt verknüpft.

WG Last Call, IETF Last Call, IESG evaluation und offene Einwände bleiben eigene Stufen. Veröffentlichung unterscheidet Internet-Draft, RFC-Stream und -Kategorie. Implementierung und Policy-Eigentümer stehen in einem Deployment-Feld. So wird weder eine Implementierung zum Konsens noch ein RFC automatisch zum Betriebsnachweis.

Die Historie darf späteren Erfolg nicht rückwirkend verteilen. Ein erfolgreicher neuer BoF verweist auf den abgelehnten Antrag und nennt die entscheidende Änderung. Die Annahme eines Drafts macht frühere Individual-Versionen nicht zu WG-Produkten. Gerade die unveränderten alten Zustände zeigen, wie ein Mandat zustande kam.

Der heutige AUDIT-Receipt lautet: individuelle Entwürfe bestehen; der BoF-Antrag 02 erhielt kritisches Scope-Feedback; im Datatracker ist er Declined; eine non-WG-Liste arbeitet an einem möglichen neuen BoF und Charter; verantwortliche Leitung, genehmigtes Charter, WG, Adoption und IETF-Konsens fehlen.

Nachweisbarkeit ohne standardmäßige Überwachung

Ein überarbeiteter Ansatz muss je Record-Typ minimieren. Inhalte, die eine Grenze nicht überschreiten müssen, können abgetrennt, gehasht oder selektiv offengelegt werden. Paarweise oder opake Kennungen sollten globale Korrelation ersetzen, wenn keine autorisierte Notwendigkeit besteht. Technische Verknüpfbarkeit ist keine Verknüpfungserlaubnis.

Auditorenzugriff braucht einen eigenen Zweck und eine eigene Genehmigung. Debugging, Vertragsbeweis, Sicherheitsuntersuchung und Regulierung rechtfertigen unterschiedliche Fristen. Lücken, Verweigerungen und nicht verfügbare Belege müssen sichtbar bleiben. Ein Receipt darf nur den gebundenen Datensatz abdecken, nicht stillschweigend alle relevanten Ereignisse.

Auf der neuen Liste lässt sich aus diesen Grenzen ein Charter machen: Protokollfragen von Deployment-Profilen, organisatorischen Policies und Rechtsbegriffen trennen; Threat Model und Privacy als Deliverables aufnehmen; die Bedeutung von „intent“ technisch begrenzen. Die Bezeichnung als Liste schmälert diese Aufgabe nicht. Sie schützt sie vor vorweggenommener Autorität.