Zusammenfassung

  • Steven Mihs erster Entwurf für eine „Disclosure Envelope“ wurde am 27. September angekündigt. Er ist eine individuelle Einreichung ohne Billigung oder formalen Normungsstatus bei der IETF.
  • Der Vorschlag belässt die signierte Agent Action Capsule unverändert und ergänzt wahlweise den ursprünglichen Eingabe- oder Ausgabewert außerhalb dieser Kapsel. Der Prüfer muss sowohl den Basisdatensatz als auch jeden offengelegten Wert gesondert prüfen.
  • Stimmen berechneter und früher festgehaltener Hash überein, ist eine Bindung belegt. Daraus folgen weder die Wahrheit des Inhalts noch die Rechtmäßigkeit seiner Weitergabe oder Vertraulichkeit nach dem Versand.

Bei einer späteren Prüfung liegt oft nur eine kryptografische Spur vor. Sie kann zeigen, dass sich ein Betreiber auf eine bestimmte Eingabe eines Agenten festgelegt hat, ohne diese Eingabe damals im Klartext zu veröffentlichen. Soll nun ein einzelner Prüfer den Inhalt sehen, entsteht ein Konflikt: Das Hinzufügen zur signierten Akte würde die Akte ändern, ein bloß daneben gelegter Text wäre noch kein Nachweis. Die neue individuelle Vorlage draft-mih-agent-disclosure-envelope-00 beschreibt eine Lösung für genau diese Lücke. Sie belegt keine bereits erfolgte Einführung bei einem Betreiber.

Die Ankündigung vom 27. September nennt Steven Mih als Autor. Der IETF-Datatracker führt die Vorlage als aktiven individuellen Internet-Draft und weist darauf hin, dass sie nicht von der IETF gebilligt ist und keinen formalen Stand im Standardisierungsprozess hat. Grundlage ist Mihs gesondert vorgeschlagenes Agent-Action-Capsule-Profil. Darin stehen in agent_input_digest und agent_output_digest lediglich SHA-256-Hashwerte über nach RFC 8785 kanonisierte JSON-Werte. Die Rohdaten selbst sind in diesen Feldern nie Bestandteil des signierten und gegebenenfalls registrierten Dokuments gewesen.

Die neue Hülle enthält die ursprüngliche Kapsel und daneben optional disclosures. Zunächst dürfen nur agent_input und agent_output als Klartextwerte erscheinen. Fehlt einer, ist er im Sinne des Entwurfs zurückgehalten, nicht widerlegt oder nachweislich nie vorhanden. Die Hülle wird nicht als signierte Erklärung beim SCITT-Transparenzdienst eingereicht. Da die Ergänzungen außerhalb der ursprünglichen Signatur und der Berechnung von capsule_id liegen, lässt sich dieselbe Kapsel mehreren Prüfern mit unterschiedlichem Zusatzmaterial zeigen. Der gemeinsame Bezeichner schützt die Identität des Ausgangsdatensatzes, nicht die Qualität jedes nachträglichen Anhangs.

Deshalb fordert der Text zwei getrennte Prüfergebnisse. Erst ist die Kapsel gemäß dem Basisprofil zu prüfen. Dann wird für jede Offenlegung der gesamte JSON-Wert kanonisiert, neu gehasht und mit dem festgehaltenen Hash verglichen. Der Entwurf unterscheidet Übereinstimmung, Abweichung, nicht zugelassene Felder und einen fehlenden oder falsch geformten Ausgangshash. Ein passender Klartext heilt keine fehlerhafte Kapsel; eine gültige Kapsel bestätigt keinen ungelesen übernommenen Klartext. Wer allein aus dessen Anwesenheit eine grüne Prüfmarke ableitet, wertet eine unsignierte Ergänzung unzulässig auf.

Ein anderer Entwurf zur selektiven Offenlegung behandelt ein anderes Ausgangsproblem. Dort wird ein Feld verborgen, das sonst im signierten Nutzinhalt lesbar wäre. Hier war das maßgebliche Feld stets ein Hash. Die Hülle liefert später einen möglichen Urwert für den Vergleich und baut das unterschriebene Dokument nicht um. Auch eine erfolgreiche Übereinstimmung kann nur diese Korrespondenz stützen. Sie beweist weder, dass die Eingabe sachlich richtig war, noch dass die Ausgabe des Agenten zulässig oder sicher war.

Die Offenlegung selbst hat eine klare Datenschutzgrenze. Jeder Empfänger der mit Klartext gefüllten Hülle kann diesen Wert lesen. Der Vorschlag enthält weder empfängerbezogene Verschlüsselung noch eine Sperre für weitere Kopien. Ein Herausgeber kann unterschiedliche Hüllen für unterschiedliche Prüfer herstellen, muss aber außerhalb dieses technischen Vergleichs entscheiden, wer welche Daten wirklich sehen soll. Daniel Kade leitet daraus eine Governance-Frage ab: Die Festigkeit eines früheren Belegs und die Berechtigung zur späteren Preisgabe sind verschiedene Kontrollflächen.

Aus dem Entwurf folgt kein Vorwurf gegen ein tatsächlich betriebenes System und keine neue IETF-Pflicht.

Quellen