Ich dachte ursprünglich, dass die Policy-Identifier von @NewtonProtocol hauptsächlich eine Funktion zur Versionsverwaltung seien. Nachdem ich den Autorisierungsfluss genauer betrachtet hatte, begann ich zu erkennen, dass sie Teil des Sicherheitsmodells des Protokolls sind und nicht nur einfache Buchführung.
Der Grund dafür ist, dass die Autorisierung nicht ausschließlich durch wiederverwendbare Policy-Logik bestimmt wird. Ein PolicyClient liefert außerdem strukturierte Konfigurationen wie Ausgabenlimits, genehmigte Empfänger, gerichtsstandsbezogene Einschränkungen oder andere betriebliche Vorgaben. Diese Werte werden zusammen mit der Policy ausgewertet, sodass die resultierende Autorisierung sowohl von der Policy-Definition als auch von der Konfiguration abhängt, die sie begleitet.
Diese Beziehung wird umso bedeutsamer, wenn sich der PolicyClient ändert. Newton erzeugt eine neue Richtlinienkennung, sobald sich die Konfiguration ändert, und Beglaubigungen, die unter der vorherigen Kennung erstellt wurden, sind für den aktualisierten Client nicht mehr gültig. Statt zuzulassen, dass alte Genehmigungen den sich weiterentwickelnden Betriebsregeln folgen, bindet das Protokoll jede Autorisierung an genau die Konfiguration, die sie erzeugt hat.
Die Entwurfsänderungen verändern die Grenze.
Aus architektonischer Perspektive macht dies die Konfiguration zu einem Bestandteil der Integrität der Autorisierung, statt zu einem Implementierungsdetail. Entwickler können dieselbe Rego-Richtlinie in mehreren Anwendungen wiederverwenden und dabei unterschiedliche operative Limits über die Konfiguration anwenden, aber die Genehmigungen bleiben an die konkrete Umgebung gebunden, in der sie ausgewertet wurden.
Aber etwas ließ mir keine Ruhe.
Viele Richtlinien stützen sich weiterhin auf Informationen, die außerhalb der Blockchain entstehen. Newton adressiert dies durch PolicyData-Oracles, die als isolierte WASM-Komponenten laufen und strukturierte Laufzeitdaten für eine deterministische Richtlinienauswertung zurückgeben. Die Laufzeit beschränkt den Zugriff auf private Netzwerke, und Ausführungsfehler oder strukturierte Anwendungsfehler verhindern, dass nicht verfügbare Daten zu erfolgreichen Autorisierungen werden. Dennoch verlagert sich die Verantwortung auf Oracle-Entwickler, -Betreiber und -Richtlinienautoren: Sie müssen festlegen, wie externe Informationen die Entscheidungen der Richtlinie beeinflussen sollen.
Es entfernt das Vertrauen nicht. Es verlagert es.
Das Ablaufdatum der Beglaubigung führt eine weitere Verantwortungsschicht ein. Kurze Gültigkeitszeiträume verringern Replay-Möglichkeiten, während längere Zeiten die Bedienbarkeit verbessern, indem sie den Nutzern mehr Zeit geben, die genehmigten Transaktionen auszuführen. Jede Anwendung entscheidet letztlich, wo dieses Gleichgewicht liegen soll.
Für Entwickler verlagert diese Architektur die Weiterentwicklung von Richtlinien weg von Vertrags-Upgrades hin zu konfigurierbaren Autorisierungsebenen. Für Betreiber werden zuverlässige externe Daten Teil einer sicheren Autorisierung. Für Nutzer steht eine Genehmigung für einen bestimmten Richtlinienkontext, nicht für eine dauerhafte Berechtigung.
Stärkt die Bindung der Autorisierung an konfigurationsspezifische Kennungen die langfristige Sicherheit, oder verlagert sie lediglich mehr Verantwortung auf das korrekte Verwalten der Konfiguration?