Summary

  • Am 23. September eröffnete die IESG den Last Call für die SATP-Architektur und die Anwendungsfälle, jeweils mit dem Ziel eines Informational RFC. Stellungnahmen sind bis 7. Oktober möglich; verabschiedet sind die Texte nicht.
  • Das empfangende Gateway kann ein privates Quellregister nicht selbst auslesen. Es erhält eine signierte Behauptung über die Sperre des Assets. Der Entwurf setzt verifizierte Betreiber, Einwilligung und Haftung während der vorübergehenden Kontrolle voraus.
  • Ein lückenloser Nachrichtenverlauf hilft bei der späteren Prüfung, belegt aber weder aus eigener Kraft den verborgenen Registerzustand noch einen rechtswirksamen Eigentumsübergang.

Was kann ein Empfänger prüfen, wenn das entscheidende Register verschlossen bleibt? Die SATP-Architektur beantwortet die technische Seite mit einem signierten Sperrvermerk des sendenden Gateways. Das Ausgangsnetz darf seine inneren Ressourcen verborgen halten. Gerade deshalb kann das Gateway am Ziel die Sperre nicht durch eigenen Blick in die Datenbank bestätigen. Es prüft die Herkunft einer Aussage, nicht unmittelbar ihren Gegenstand.

Der Entwurf stützt sich dabei auf eine Reihe von Vorleistungen. Asset, Absender und Begünstigter sollen identifiziert und die Zustimmung bereits eingeholt sein. Die Eigentümer der Gateways sollen feststehen und ihre Identität überprüft sein. Betreiber sollen für signierte Nachrichten und für das Asset haften, das ihr Gateway während der Übertragung technisch kontrolliert. Diese Passagen beschreiben Annahmen der Architektur; sie bescheinigen keinem vorhandenen Dienst die Einhaltung.

Die Transaktion zerfällt in nachprüfbare Abschnitte. Zunächst wird das Asset im Quellnetz immobilisiert und die Sperre bestätigt. Später koordiniert ein Commit-Verfahren das Löschen dort und die Erzeugung eines gleichwertigen Assets im Zielnetz. Signaturen und Verkettungen der Nachrichten schaffen Material für eine befugte Prüfung im Streitfall. Stimmt aber die lokale Ausgangsinformation nicht, bleibt auch eine perfekt signierte Falschbehauptung falsch.

Die neue Entscheidung ist noch keine Standardverabschiedung. Die Internet Engineering Steering Group bat am 23. September um Kommentare zu Revision 10 der Architektur und Revision 10 der Anwendungsfälle; Frist ist der 7. Oktober. Beide Dokumente sollen informativ sein. Der separate Kernprotokoll-Entwurf strebt den Status Proposed Standard an, durchläuft aber nicht automatisch denselben Beschluss. Die im Begleittext genannten Finanz-, Handels- und Lieferkettenbeispiele sind mögliche Anwendungen, keine Bestandsaufnahme laufender Installationen.

Eine zweite Grenze steht in der SATP-Charta: Teilnehmende Netze dürften vorher rechtliche oder andere Abmachungen benötigen; diese Regelwerke und der Nachweis ihrer Umsetzung fallen nicht in den Protokollumfang. Lu Hengs Trennung von Beleg und Entscheidungsbefugnis schärft den Punkt. Ein signierter Verlauf kann einer Streitinstanz vorliegen, ersetzt aber weder diese Instanz noch das Recht am Asset.

Sources