Zusammenfassung

  • Am 5. September erschien Revision 01 des individuellen Internet-Drafts zum Testimony Record; sie korrigiert einen zu weit gehenden Zensus-Satz, definiert die Digest-Berechnung und benennt die Grenzen des Implementierungsstands.
  • Die vier kumulativen Stufen betreffen Aufzeichnung, Erklärung, Aktionssperren und Integritätsnachweis. Ein nicht handelnder Emittent kann TR-3 jedoch durch acts:false ohne zu sperrende Aktion erfüllen und danach TR-4 erreichen.
  • Die Revision trennt Prüfungen, die der Leser aus dem Datensatz entscheiden kann, von Angaben, für die nur der Emittent einsteht, etwa die Herkunft einer Risikoklasse oder einer Genehmigeridentität.
  • Ein RFC-3161-Anker bindet einen Digest an Zeitpunkt und externe Stelle, beweist aber weder Richtigkeit noch Vollständigkeit oder das Fehlen einer verworfenen Alternativfassung.
  • Beschaffung und Aufsicht sollten eine bereichsbezogene Beweismatrix mit Ergebnissen je Stufe, verifizierten und attestierten Checks, Integritätsverfahren und Prüferidentität verlangen – keine nackte TR-4-Zahl.

Eine Spezifikation legt über sich selbst Zeugnis ab

Die IETF-Ankündigung dokumentiert ein begrenztes institutionelles Ereignis: Am 5. September wurde ein 18-seitiger Internet-Draft verfügbar. Die Datatracker-Seite setzt die notwendige Grenze. Es handelt sich um einen aktiven individuellen Entwurf, den grundsätzlich jeder einreichen kann. Er besitzt weder einen RFC-Stream noch einen verantwortlichen Area Director oder formalen Status und ist nicht vom IETF gebilligt. Die vorgesehene Kategorie „Informational“ ist Absicht des Autors, kein erreichter Standardstatus.

Innerhalb dieses Rahmens ist Revision 01 bemerkenswert, weil sie die eigene Beweislage sichtbar berichtigt. Der feste Text von Revision 00 erklärte, keines von acht untersuchten Systemen zeichne die Identität eines genehmigenden Menschen auf. Der feste Text von Revision 01 stellt klar, dass der Zensus diesen Universalsatz nicht trug. Bei vier von fünf einschlägigen, nicht vom Autor stammenden Systemen galt das Merkmal als abwesend; beim fünften blieb es unbestimmt. Die übrigen drei schlossen eigene Arbeit des Autors ein. Die weiter gehende Behauptung wurde gestrichen.

Das ist keine redaktionelle Nebensache. Ein Format, das festhalten soll, was ein Automat zu wissen und zu tun behauptete, muss für seine eigenen Aussagen zwischen „nicht vorhanden“, „nicht feststellbar“ und „in eigener Implementierung vorhanden“ unterscheiden. Die alte Formulierung verdichtete verschiedene Evidenzzustände zu einer Gewissheit, die ihre Quelle nicht hergab.

Der offizielle Versionsvergleich zeigt eine zweite Selbstkorrektur. Revision 00 nannte einen Digest, ohne Algorithmus, Serialisierung und Reihenfolge ausreichend festzulegen. Zwei Implementierungen konnten denselben Inhalt annehmen und unterschiedliche Werte bilden. Zudem nahm ein Validator den erklärten Digest hin, statt ihn neu zu berechnen. „Verifiable“ war damit aus dem Dokument allein nicht reproduzierbar.

Revision 01 verlangt nun SHA-256 über die in covers aufgeführten Einträge in definierter Reihenfolge. Sie bestimmt kompaktes JSON, Schlüsselordnung nach Unicode-Codepoints, das Weglassen von mit Unterstrich beginnenden Leserannotation, UTF-8, LF-Verknüpfung ohne abschließendes LF und Zahlenbereiche, deren Serialisierung sonst auseinanderlaufen kann. Der Referenzvalidator rechnet selbst nach. Aus einem Etikett wird dadurch zumindest eine lokal anfechtbare Behauptung.

Vier Stufen beantworten verschiedene Fragen

Das Format führt Einträge für Geltungsbereich, Überzeugung, Evidenz, Widerspruch, Entscheidung, Genehmigung und Integrität. TR-1 prüft Lesbarkeit, bekannte Versionen und Typen, Pflichtfelder, eindeutige Kennungen, zeitliche Ordnung und Widersprüche zum erklärten Bereich. TR-2 fordert Evidenzverweise für Überzeugungen – auch eine ausdrücklich leere Liste für eine unbegründete Überzeugung – sowie den Erhalt beider Seiten eines Konflikts und einer etwaigen Auflösung.

TR-3 betrifft folgenreiche Aktionen. Die Risikoeinstufung soll aus einer Quelle außerhalb der Ausgabe des vorschlagenden Modells stammen. Eine abgelehnte Aktion darf nicht zugleich als ausgeführt erscheinen. Eine ausgeführte Hochrisikoaktion benötigt eine Genehmigung mit benanntem Menschen, einer Identitätsquelle außerhalb des Modelltexts und Trennung von Genehmiger und Vorschlagendem.

TR-4 wechselt zur Integrität. Alle abgedeckten Einträge müssen vorhanden sein, der Digest muss sich ergeben und ein externer Anker muss den erklärten Wert binden. Das sind nützliche Eigenschaften. Es ist aber nicht dieselbe Eigenschaft wie wirksame Aktionskontrolle.

Der Entwurf räumt diese Vermischung ein. In Formatversion 0.2 kann ein Emittent acts:false erklären. Enthält sein Datensatz dann keine Entscheidungen, erfüllt er TR-3, weil keine Handlung zu sperren war, und kann bis TR-4 gelangen. Der präzise Bericht lautet „TR-4, record only“. Ohne den Nachsatz sieht eine bereichsgebundene Aussage wie ein allgemeines Gütesiegel aus.

Ein Beobachter oder Gedächtnisdienst ohne Aktionsbefugnis ist deshalb nicht nutzlos. Im Gegenteil: Gerade sein Datensatz kann starke Manipulationsnachweise brauchen. Falsch wäre nur, aus dieser Stärke abzuleiten, dass reale Auswirkungen durch Genehmigungsschranken gingen, obwohl Auswirkungen gar nicht zu seinem erklärten Bereich gehören.

Auch der Geltungsbereich stammt vom Emittenten

Der scope-Eintrag löst ein echtes Validierungsproblem, bleibt aber eine Selbstauskunft. Ein tatsächlich handelndes System kann sich als nicht handelnd bezeichnen und die Entscheidungsanforderungen umgehen. Zeichnet es dennoch eine Entscheidung auf, wird der Widerspruch sichtbar und TR-1 scheitert. Lässt es den gesamten Aktionspfad weg, kann der Datensatz die falsche Erklärung nicht aus sich selbst widerlegen.

Für die Beschaffung ist das praktisch. Ein Anbieter könnte ein konformes Aufzeichnungsmodul vorführen, während Konnektor, Sidecar oder Hostprozess außerhalb des erklärten Emittenten die externen Wirkungen auslöst. Der Datensatz kann intern tadellos und betrieblich unvollständig sein. Der Käufer muss daher die Ausführungsgrenze unabhängig bestimmen: welcher Prozess vorschlägt, freigibt, versendet und die Wirkung beobachtet; welche Pfade den Recorder umgehen; und welches externe Material den erklärten Bereich mit dieser Architektur verbindet.

Das öffentliche Repository des Autors stellt Spezifikation, Validator, Adapter und Konformitätskorpus bereit. Das ist prüfbarer als ein reines Versprechen. Es bleibt vom Autor kontrollierte Evidenz. Der neue Implementierungsabschnitt sagt ausdrücklich, dass zum Stichtag jede bekannte Implementierung von ihm stammte. Zwei getrennt geschriebene Validatoren können Unklarheiten und innere Abweichungen aufdecken; sie belegen keine unabhängige Interpretation durch einen zweiten Implementierer.

Auch das Zensus-Verzeichnis ist wertvoll: Es fixiert untersuchte Commits, verlangt Belege für Abwesenheitsurteile und weist Konflikte oder Unbestimmtheit aus. Es dokumentiert sogar Mängel in der eigenen Arbeit des Autors. Zu einem unabhängigen Audit wird es dadurch nicht. Rubrik, Referenzsystem und Beurteilung liegen bei derselben Person.

Verifiziert und attestiert können dieselbe Stufe tragen

Revision 01 führt eine Unterscheidung ein, die mehr Information enthält als der Ordinalwert. Einen verifizierten Check kann ein Leser aus dem vorliegenden Datensatz entscheiden: Existiert der zitierte Evidenzeintrag? Bleiben die Konfliktseiten erhalten? Wurde eine Ablehnung nicht als ausgeführt protokolliert? Passt der Digest zu exakt den abgedeckten Einträgen? Signiert ein Zeitstempel den richtigen Imprint?

Bei einem attestierten Check sagt dagegen der Emittent, was außerhalb des Datensatzes geschehen sein soll. Die genannte Risikoquelle könnte fehlen. Der Name des Genehmigers könnte nicht aus der behaupteten authentisierten Sitzung stammen. Eine Replay-Engine könnte ein anderes Ergebnis liefern. Solche Pflichtangaben sind nützlich, weil eine konkrete Aussage später widerlegt werden kann. Das Schema verwandelt die Aussage aber nicht in unabhängige Evidenz.

Deshalb können zwei Datensätze mit sehr verschiedener Beweiszusammensetzung dieselbe Stufe tragen. Der eine besteht überwiegend aus wiederholbarer Arithmetik über erhaltene Bytes. Beim anderen liefert der geprüfte Emittent zentrale Tatsachen selbst. Die Überschrift „TR-4“ entfernt diesen Unterschied.

Hinzu kommen verschieden starke Integritätsverfahren. Ein selbst berechneter Digest zeigt spätere Änderungen durch Dritte, hindert den Emittenten aber nicht daran, eine Alternative zu erzeugen und neu zu hashen. Eine Signatur stellt Identität hinter die Aussage, abhängig von Schlüsselverwahrung und Vertrauensregeln. Ein externer Zeitstempel verlagert Imprint und Zeitangabe nach außen. RFC 3161 verlangt vom Antragsteller die Prüfung, dass der Token den gewünschten Imprint und eine akzeptable Policy enthält. Der Token beweist dennoch nicht Richtigkeit, Vollständigkeit oder Einzigartigkeit des Datensatzes.

RFC 8785 bietet Kontext für kanonisches JSON; der Entwurf definiert zusätzlich seine eigene Regel für die abgedeckten Einträge. RFC 9162 und der Arbeitsentwurf zur SCITT-Architektur zeigen, wie Nachweise in Transparenzinfrastruktur außerhalb eines einzelnen Emittenten abgelegt werden können. Keines dieser Systeme kann nachträglich beweisen, dass der selbst erklärte Bereich vollständig war oder eine Überzeugung wahr ist.

Aus der Stufe muss eine Beweismatrix werden

Der überarbeitete Entwurf empfiehlt bereits, jede Stufe einzeln und zusammen mit dem erklärten Bereich zu berichten. Für folgenreiche Nutzung sollte das Pflichtangabe sein. Eine knappe Matrix nennt die exakte Spezifikationsfassung und ihren Hash, Emittent und Ausführungsgrenze, den Geltungsbereich samt Kennzeichnung als selbst erklärt oder extern belegt, das Ergebnis jeder TR-Stufe, Kennungen und Anzahl verifizierter wie attestierter Checks, Integritätsverfahren und abgedeckte Einträge, Ankerstelle, Policy und Prüfergebnis, Validator-Build, Korpusversion und Beobachtungszeit.

Die Matrix erfindet keine zusätzliche Zertifizierung. Sie bewahrt starke Teilbeweise, ohne Schwächen zu verstecken. Ein externer Integritätsanker kann gültig sein, obwohl die Herkunft einer Genehmigeridentität unbestätigt bleibt. Eine reale Aktionssperre kann nachgewiesen sein, obwohl dauerhafte Verankerung fehlt. Beide Aussagen dürfen gleichzeitig sichtbar bleiben.

Ungeklärt bleibt die Datenschutzgrenze. Der Entwurf empfiehlt, sensible Inhalte nicht zu kopieren, sondern gegebenenfalls Quellkennung und Digest aufzubewahren und Schwärzung sichtbar zu machen. Zugleich erkennt er den Konflikt zwischen nur anhängbarer Historie und Löschungspflicht. Umschreiben zerstört Beweiskontinuität; unter einem Löschmarker behalten ist keine Löschung. Eine Konformitätsstufe entscheidet diese Rechts- und Architekturfrage nicht.

Ebenso setzt die Spezifikation nicht den EU AI Act um, nur weil sie Protokollierung und menschliche Aufsicht behandelt. Sie weist diesen Schluss ausdrücklich zurück. Rechtliche Genügsamkeit beurteilen Verpflichtete und zuständige Institutionen.

Revision 01 ist somit glaubwürdiger, gerade weil sie eine schwache Aussage und nicht reproduzierbare Technik korrigiert. Die Governance-Lehre besteht nicht darin, diesen Fortschritt in ein größeres Mandat umzudeuten. Der Datensatz kann zeigen, was er enthält, Widersprüche erhalten und seine Bytes binden. Wer sich auf ihn stützt, muss weiterhin fragen, was beobachtet, was nur attestiert, was vom Emittenten ausgeschlossen und von wem die verbleibende Unsicherheit akzeptiert wurde.

Quellen

  1. IETF-Ankündigung zu Revision 01
  2. Status im IETF Datatracker
  3. Testimony Record, Revision 01
  4. Testimony Record, Revision 00
  5. Offizieller Vergleich 00–01
  6. Repository Machine Testimony
  7. Verzeichnis des Konformitätszensus
  8. RFC 3161 – Time-Stamp Protocol
  9. RFC 8785 – JSON Canonicalization Scheme
  10. RFC 9162 – Certificate Transparency 2.0
  11. SCITT-Architektur, Revision 22
  12. Heng Lu über den Vorrang von Running Code