Zusammenfassung

  • draft-sato-soos-pt-03 wurde am 5. September 2026 angekündigt. Der Datatracker führt ihn als aktiven individuellen Internet-Draft ohne IETF-Billigung, formalen Stand, RFC-Stream, zuständigen Area Director oder Telechat-Termin.
  • Revision 02 legte ProgressiveTrustSummary in einen HEM-Kontext, ließ aber die Signaturkomposition offen. Revision 03 verlangt die Übersicht als Feld in jeder HEM Escalation Request, bevor die GEC sie signiert.
  • Eine außerhalb des signierten Umschlags der Anfrage zugestellte Übersicht darf die Oberfläche des menschlichen Principals laut neuem Text nicht als maßgeblich behandeln.
  • pt_summary_hash bleibt ein SHA-256-Wert über kanonischem JSON und dient der Kontrolle nach dem Extrahieren. Authentizität beim Entscheider stammt aus kernel_signature der umschließenden Anfrage.
  • Ein gemeinsamer Beleg sollte hem_id, Signaturpräimage, Unterzeichner und Schlüssel, Prüfergebnis, Feldpfad, extrahierten Hash und Transportänderungen erhalten. Das ist Daniel Kades Empfehlung, keine IETF-Vorgabe.

Ein richtiger Wert kann zur falschen Anfrage gehören

Die Ankündigung vom 5. September beschreibt Progressive Trust als verhaltensbezogene Langzeitmessung für KI-Agenten. Aus signierten Ereignissen sollen fünf Dimensionen und daraus strukturierte Empfehlungen zur künftigen Autorität entstehen. Im Datatracker ist Tom Satos Revision 03 ein aktiver individueller Internet-Draft. Sie ist nicht von der IETF gebilligt und besitzt dort keinen formalen Stand. RFC-Stream, verantwortlicher Area Director und Telechat fehlen. „Standards Track“ ist das Ziel des Autors.

Die fünf Dimensionen betreffen kalibrierte Selbsteinschätzung, den richtigen Zeitpunkt für menschliche Hilfe, Wirksamkeit, Präzision und Anpassung nach einer Zurückweisung. Eine ProgressiveTrustSummary bündelt Werte, Trends, Sitzungszahlen, eine zusammengesetzte Anzeige, offene Empfehlungen und pt_summary_hash.

Der sensible Übergang beginnt bei der Darstellung. Ein Wert von 0,88 trägt keine natürliche Anfragekennung in sich. Er muss zum richtigen Agenten, Berechnungszeitpunkt und hem_id gehören und gemeinsam mit Auslöser, Handlung und Empfänger geprüft werden. Ein Analysedienst kann eine ältere Übersicht zwischenspeichern; ein Gateway kann sie zur Übersetzung herauslösen; eine verspätete Antwort kann neben der nächsten Anfrage erscheinen. Jeder Einzelwert kann korrekt sein, während die Zuordnung falsch ist.

PT-03 löst keine Bewertungsfrage, sondern eine Bindungsfrage: Für welches Gesamtobjekt hat sich der Unterzeichner verbürgt?

„Im Kontext“ war noch keine Signaturreihenfolge

Die eingefrorene Revision 02 verlangte, dass die GEC bei jeder Eskalation eine Übersicht in den HEMContext einfügt. Sie schrieb auch den Berechnungszeitpunkt vor und enthielt den Hash. Der Text schloss aber nicht aus, die Hauptanfrage zuerst zu signieren und die Übersicht anschließend über einen separaten Aufruf in einer Seitenkarte zu ergänzen.

Der offizielle Versionsvergleich zeigt die Korrektur. Revision 03 macht die Übersicht zu einem Feld innerhalb jeder HEM Escalation Request. Die GEC muss das Feld vor der Signatur nach HEM Abschnitt 18.8 in die Anfrage komponieren. Eine außerhalb des signierten Umschlags eintreffende Übersicht ist für die Oberfläche des Empfängers nicht maßgeblich.

Der Entwurf schreibt, die Änderung reagiere auf den zentralen Befund eines WIMSE Security Review. In der gewöhnlichen Suche nach öffentlichen Primärquellen ließ sich kein gesondertes Archivexemplar dieser Prüfung finden. Daher ist nur die Zuschreibung des Entwurfs berichtbar, nicht ein rekonstruierter Prüfbericht. Die Textänderung zwischen 02 und 03 ist dagegen direkt nachprüfbar.

Die Reihenfolge macht den Unterschied. „Zusammen anzeigen“ ist eine Präsentationsanweisung. „Vor dem Signieren einbetten“ ist eine prüfbare Zustandsfolge. Im zweiten Fall verpflichten sich Signatur und Schlüssel gleichzeitig auf Anfragekennung, Auslöser, Handlungsrahmen und Übersicht.

Der Hash prüft Gleichheit, nicht Zuständigkeit

pt_summary_hash ist als SHA-256 des kanonischen JSON beschrieben. Revision 03 nennt ihn ausdrücklich ein Hilfsmittel für die unabhängige Nachprüfung nach der Extraktion, etwa im Audit. Wer die Übersicht aus der Anfrage nimmt, kann damit belegen, dass die betrachtete Repräsentation unverändert blieb. Für den Menschen bei der Eskalation schafft der Hash aber keine Authentizität.

RFC 8785 erläutert das allgemeine Problem: JSON benötigt für wiederholbare Hash- und Signaturvorgänge eine deterministische kanonische Repräsentation. Das beseitigt Unterschiede bloßer Serialisierung. Es beantwortet nicht, wer die Daten auswählte, zu welcher Anfrage sie gehören oder wer sie beim Entscheiden sah. Wer ein nicht authentisiertes Objekt ersetzen kann, kann auch dessen neuen Hash berechnen.

HEM Revision 07 beschreibt die umschließende Schicht. Die GEC signiert die vollständige HEM Escalation Request mit Ed25519; kernel_signature deckt die kanonische Serialisierung aller anderen Felder ab. HEM-07 bezeichnet progressive_trust_summary außerdem als erforderliches Anfragefeld. Der Verifier prüft damit eine verbundene Aussage: Diese GEC hat diese Übersicht dieser Eskalation zugeordnet.

Auch eine gültige Signatur beweist keine inhaltliche Wahrheit. Ereignisse können fehlen, Berechnungen fehlerhaft, Schlüssel kompromittiert und menschliche Entscheidungen schlecht sein. Die Signatur belegt nach den Annahmen der Entwürfe Herkunft und Unversehrtheit. Sie macht Austausch und Fehlzuordnung erkennbar, nicht die Welt hinter dem Datensatz unfehlbar.

Erst prüfen, dann die Vertrauensfarbe setzen

Die Benutzeroberfläche sollte die Reihenfolge nicht umkehren. Zuerst werden Gesamtanfrage, hem_id, Signaturschlüssel und kernel_signature geprüft. Danach lässt sich die Übersicht extrahieren, ihr Hash für den Auditbeleg neu berechnen und ihre verständliche Darstellung erzeugen. Eine grüne Karte vor Abschluss der äußeren Prüfung leiht einer Ladephase Autorität.

Für Vermittler gilt dasselbe. HEM-07 verlangt von zuständigen Lieferkomponenten, eine Anfrage bei gescheiterter Kernel-Signatur nicht weiterzuleiten. Ein Relay darf transportieren und darstellen. Es darf nicht durch Zusammenbau vertrauenswürdig aussehender Einzelteile zum neuen Autor werden. Ändert es die Serialisierung, muss es die signierte Präimage oder einen reproduzierbaren Prüfbeleg erhalten.

Die Entscheidung bleibt beim Menschen. Die Übersicht ist informativ: Ein Principal kann trotz niedriger Werte zustimmen oder trotz hoher Werte abbrechen. Durch die Einbettung erhält die Metrik keine Stimme. Stattdessen wird feststellbar, welche Information den menschlichen Machtakt begleitet hat.

Ein Beleg muss die Verbindung konservieren

Die kleinste brauchbare Betriebserinnerung ist ein verbundener Verifikationsbeleg. Er sollte hem_id, Anfrageversion, signierte Bytes oder kanonische Präimage, kernel_signature, Unterzeichner, Schlüsselkennung, Prüfzeit und Ergebnis enthalten. Hinzu kommen Feldpfad und Berechnungszeit der Übersicht, der nach Extraktion neu berechnete Hash sowie jede Umformung durch Relay oder Oberfläche. Das ist meine Empfehlung, nicht normativer Text aus PT oder HEM.

Negative Fälle sollten den Testplan bestimmen. Eine gültige Übersicht mit einer anderen hem_id muss scheitern. Ein geänderter Wert mit altem Hash muss scheitern. Eine ausgetauschte Übersicht mit frisch passendem Hash, aber ohne gültige Außensignatur muss ebenfalls scheitern. Tauscht die Oberfläche nach erfolgreicher Prüfung die verständliche Erklärung, muss eine Präsentationsprüfung den Unterschied erkennen. Ein unbekannter Schlüssel bleibt ungelöst; er wird nicht durch den letzten grünen Zustand ersetzt.

Heng Lus Running-Code Primacy liefert dafür eine Leseregel: Veröffentlichung ist kein Betriebsnachweis; unabhängige Betreiber müssen die Zustandsregel lokal testen können. Seine Minimum Initial Specification spricht für eine dünne gemeinsame Schicht. Eine Anfrage, eine umschließende Signatur und ein erhaltener Prüfpfad reichen hier aus. Die Essays sind Analysemaßstab, kein Beleg für PT-Nutzung.

Nachweisbare Korrektur, noch kein Einsatznachweis

Weder der PT- noch der HEM-Datatracker belegt eine unabhängige Implementierung, einen Interoperabilitätstest, Produktion, einen Angriff, ein kompromittiertes Relay, einen Vorfall oder IETF-Adoption. Beide Texte bleiben individuelle Entwürfe und können geändert werden oder verfallen.

Die belastbare Nachricht ist deshalb eng: PT-03 benennt jetzt das signierte Objekt, das die menschlich sichtbare Vertrauensübersicht tragen soll, und beschränkt den Hash auf die Kontrolle nach der Extraktion. Der nächste Fortschritt wäre nicht ein weiteres Vertrauenswort, sondern zwei Implementierungen, die dieselben Fehlpaarungen ablehnen und denselben verbundenen Beleg wiedergeben können.

Quellen

  1. IETF-Ankündigung zu draft-sato-soos-pt-03
  2. Datatracker — Progressive Trust
  3. IETF-Archiv — PT-03
  4. IETF-Archiv — PT-02
  5. Offizieller Vergleich PT-02/PT-03
  6. IETF-Archiv — HEM-07
  7. Datatracker — Human Escalation Mechanism
  8. RFC 8785 — JSON Canonicalization Scheme
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — minimale Ausgangsspezifikation
  11. Heng Lu — Realität statt Fürsprache