Ursprünglich dachte ich, dass @NewtonProtocol ‚s wichtigste Leistung darin bestand, die Autorisierung von der Anwendungslogik zu trennen. Nach mehr Zeit mit der Architektur stellte ich jedoch fest, dass ich mich auf etwas deutlich Kleineres konzentriere: die Entscheidung, Policy-Identifikatoren an die PolicyClient-Konfiguration zu binden, statt die Konfiguration als nebensächlichen Detail zu behandeln.
Dieses Mechanismus verändert, wie die Autorisierungs-Historie erhalten bleibt.
Ein PolicyClient verweist auf eine wiederverwendbare Rego-Richtlinie, während er zur Laufzeit Parameter wie Ausgabenlimits, genehmigte Empfänger, gerichts-/gebietliche Einschränkungen oder andere operative Rahmenbedingungen bereitstellt. Die Richtlinienlogik bleibt gleich, aber die Konfiguration definiert die Umgebung, in der diese Logik ausgewertet wird. Anstatt diese Grenzen in jeder Richtlinie einzubetten, übergibt Newton sie als strukturierte Konfigurationsdaten während der Auswertung.
Interessant wird es, wenn sich diese Grenzen ändern.
Statt zuzulassen, dass dieselbe Autorisierungsidentität fortbesteht, erzeugt Newton eine neue Richtlinienkennung, sobald sich die PolicyClient-Konfiguration ändert. Bestätigungen, die unter der vorherigen Konfiguration erstellt wurden, sind nicht mehr gültig, sobald der Client auf die neue Kennung verweist. Die Autorisierung bleibt daher mit der exakten Konfiguration verknüpft, die sie erzeugt hat, statt nur mit der wiederverwendbaren Richtlinie selbst.
Aus architektonischer Perspektive entsteht dadurch eine stärkere Verbindung zwischen Genehmigung und Kontext. Zwei Anwendungen können identische Richtlinienlogik ausführen, aber unterschiedliche operative Grenzen durchsetzen. Wenn man diese Umgebungen als unterschiedliche Autorisierungsidentitäten behandelt, lässt sich leichter unterscheiden, welchen Genehmigungen welche Konfiguration zugeordnet sind.
Aber irgendetwas ließ mich nicht los.
Konfiguration ist nur eine Quelle der Veränderung. Einige Autorisierungsentscheidungen hängen außerdem von Informationen ab, die außerhalb der Blockchain existieren. Newton adressiert das über PolicyData Oracles, die als isolierte WASM-Komponenten laufen. Strukturierte Eingaben gelangen in die Komponente, die zulässigen Operationen werden in einer Sandbox ausgeführt, und strukturiertes JSON steht während der Richtlinienevaluierung zur Verfügung.
Die Isolation ist bewusst. Die Oracle-Ausführung blockiert Loopback-Adressen, private Netzwerkbereiche und Link-Local-Schnittstellen, während HTTP-Anfragen auf öffentlich erreichbare Endpunkte begrenzt werden. Entwickler können außerdem JSON-Schemata definieren, damit ungültige Anfragen bereits vor dem Start der Ausführung abgelehnt werden können.
Das Design verändert die Grenze.
Oracle-Antworten führen außerdem zu einer weiteren Unterscheidung, die mich besonders aufgehalten hat. Wenn externe Informationen nicht beschafft werden können oder die Validierung fehlschlägt, können Richtlinien strukturierte Fehlerinformationen interpretieren und die Autorisierung verweigern. Wenn die WASM-Komponente selbst nicht erfolgreich ausgeführt werden kann, wird die Auswertung stattdessen mit einem DataProviderError abgebrochen, statt ein normales Autorisierungsergebnis zu erzeugen.
Das entfernt kein Vertrauen. Es verlagert es nur.
Die Verantwortung verschiebt sich hin zu denen, die Richtlinien konfigurieren, Oracle-Komponenten entwerfen und entscheiden, wie Fehler die Ergebnisse der Autorisierung beeinflussen sollen. Das Protokoll stellt wiederverwendbare Mechanismen bereit, doch Anwendungen bleiben verantwortlich für die Wahl der Ablaufzeiten, die operativen Grenzen und das Richtlinienverhalten, das zu ihren eigenen Anforderungen passt.
Die gleiche Balance zeigt sich auch in Bestätigungen. Jede Autorisierung enthält einen Wert für expireAfter. Dadurch können Anwendungen kürzere Gültigkeitsfenster gegen weniger Replay-Möglichkeiten eintauschen oder längere Fenster für eine bessere Nutzbarkeit wählen. Das Protokoll bietet Flexibilität, ohne vorzuschreiben, wo diese Balance festgelegt werden soll.
Die Implementierung ist wichtiger als der Mechanismus.
Für Entwickler, die Systeme rund um Sanktionsscreening, Identitätsprüfung, Treasury-Kontrollen, Stablecoin-Operationen, Übertragungen realer Vermögenswerte oder autonome Softwareagenten aufbauen, verschiebt sich durch diese Architektur der Ort der Komplexität. Anstatt die Autorisierungslogik über den Anwendungscode zu verteilen, bündelt man die Verantwortung in wiederverwendbaren Richtlinien, konfigurationsbewussten Kennungen, isolierten Datenanbietern und zeitgebundenen Bestätigungen, deren Bedeutung von den Bedingungen abhängt, unter denen sie erstellt wurden.
Stärkt die Bindung einer Autorisierung an konfigurationsspezifische Richtlinienkennungen die Integrität der langfristigen Autorisierung, oder verlagert sie lediglich die operative Verantwortung auf eine andere Ebene?