Zusammenfassung

  • Der IETF Last Call für SATP Core 17 läuft bis 9. Oktober 2026; Architecture und Use Cases 10 laufen bis 7. Oktober und sind weiterhin Entwürfe.
  • Die signierte, hashverkettete Folge endet mit ACK-Final-Receipt, der Zuweisungsaussage des empfangenden Gateways.
  • Burn- und Mint-Belege sind netzwerkspezifisch. Core 17 unterstützt keine Sitzungswiederaufnahme; gemeinsame Crash-Log-Semantik bleibt künftige Arbeit.

Ein geordneter Nachweis zwischen Gateways

SATP koordiniert ein sendendes und ein empfangendes Gateway für zwei unterschiedliche Asset-Netze. Core 17 beschreibt Burn-and-mint in einem Zwei-Phasen-Ablauf mit ACID-Ziel. Der Entwurf befindet sich im Last Call für Proposed Standard; die Begleittexte streben Informational-Status an. Das ist eine Prüfphase, keine Feststellung über Einsatz oder Reife eines Produkts.

Der gemeinsame Transcript ist dennoch präzise. In Commit-Ready behauptet das empfangende Gateway, ein äquivalentes Asset erzeugt zu haben. Commit-Final enthält die signierte Burn-Aussage des sendenden Gateways. ACK-Final-Receipt bestätigt als Aussage des Empfängers die Zuweisung an den vorgesehenen Begünstigten. Signaturen und Vorgänger-Hashes machen Urheber und Reihenfolge überprüfbar.

Damit lässt sich belegen, welches Gateway welche Erklärung abgab. Die Signatur misst aber nicht selbst den externen Zustand, den die Erklärung beschreibt. Architecture grenzt die Burn- und Mint-Mechanismen sowie deren kryptografische Beweise ausdrücklich als netzwerkspezifisch aus. Der SATP-Transcript und die Zustandsbelege beider Netze bleiben zwei verbundene, aber verschiedene Beweisschichten.

Nach Commit-Final wird die Trennung besonders wichtig. Vor dem Burn kann ein Abbruch mit begrenztem Aufwand rückgängig gemacht werden. Danach ist er wirkungslos: Das Ursprungs-Asset wurde verbrannt, das Ziel-Asset erzeugt und das empfangende Gateway hat der Zuweisung zugestimmt. Wer an diesem Punkt Wert freigibt, braucht sowohl die Protokollfolge als auch die Belege der Systeme, die die irreversiblen Änderungen vollzogen.

Die Lücke zwischen Log und Wiederaufnahme

Architecture verpflichtet Implementierungen zu Ereignislogs und Checkpoints. Ein Backup-Gateway könnte übernehmen, wenn das Log zugänglich und standardisiert wäre. Der Neustartpunkt hängt jedoch von der Wiederherstellungsstrategie der Implementierung ab; Semantik und Syntax des Crash-Management-Logs gelten als künftige Arbeit. Core 17 sagt ausdrücklich, dass Sitzungswiederherstellung und -fortsetzung in dieser Version nicht unterstützt werden.

Das beweist keine Schwäche eines konkreten Produkts. Ein Betreiber kann Zustand replizieren, Schlüssel absichern und Failover testen. Noch fehlt aber ein portabler Vertrag, mit dem ein Ersatz die Checkpoints einer anderen Implementierung allein aus dem gemeinsamen Standard interpretiert.

TLS 1.3 schützt den Kanal, JWT kann eine Aussage codieren und Syslog kann eine Log-Struktur inspirieren. Keines dieser Mittel liest von sich aus beide Asset-Netze, weist die Kontrolle des Begünstigten nach oder bestimmt den sicheren Neustartpunkt.

Das Vertrauensmodell ist offen benannt: Gateways gelten für die Transferaufgaben als vertrauenswürdig und stützen sich auf ihre lokalen Netzdaten. Zugleich behandeln die Sicherheitsüberlegungen unehrliche Gateways, zurückgehaltene Nachrichten und kompromittierte Schlüssel. Heng Lus Trennung von Vertrauen und Mechanismus sowie von protokollierter Aussage und Betriebswahrheit bewahrt hier die richtige Reichweite.

Quellen