Backend-Systeme treffen selten Autorisierungsentscheidungen ausschließlich anhand der eingehenden Anfrage. Sie stützen sich oft auf externe Informationen wie Benutzerrollen, Kontostatus, Compliance-Daten oder anwendungsspezifische Metadaten. Newton erweitert dieses Prinzip in seiner policy-getriebenen Architektur durch Data Provider, wodurch die Policy-Auswertung relevante Kontextinformationen einbeziehen kann, statt sich nur auf Transaktionsparameter zu verlassen.
Das Engineering-Problem
Eine Transaktionsanfrage beantwortet typischerweise, was jemand vorhat zu tun, aber nicht unbedingt, ob es erlaubt sein sollte.
Beispielsweise benötigt eine Richtlinie möglicherweise zusätzlichen Kontext, bevor sie eine Aktion autorisiert. Sich ausschließlich auf Transaktionsdaten zu verlassen, würde die Arten von Autorisierungsregeln begrenzen, die Entwickler ausdrücken können.
Newton löst diese Herausforderung, indem es Data Provider als Teil seiner dokumentierten Architektur zur Richtlinienauswertung einführt. So können Richtlinien die Informationen erhalten, die für Autorisierungsentscheidungen benötigt werden, ohne diese Logik direkt in Smart Contracts einzubetten.
Was sind Data Provider?
Laut der Newton-Dokumentation sind Data Provider Komponenten, die während der Richtlinienauswertung kontextbezogene Informationen bereitstellen.
Statt jede Autorisierungsentscheidung als eine feste Onchain-Regel zu behandeln, kann die Policy Engine Transaktions-Intents anhand relevanter Daten auswerten, die über konfigurierte Provider bereitgestellt werden. So bleibt die Policy-Logik deklarativ, während Entscheidungen Informationen berücksichtigen können, die über die unmittelbare Transaktion selbst hinausgehen.
Wichtig ist: Data Provider ersetzen nicht die Richtlinienauswertung – sie unterstützen sie, indem sie die benötigten Eingaben bereitstellen, damit Richtlinien bestimmen können, ob eine Aktion die definierten Autorisierungsanforderungen erfüllt.
Wo sie in der Architektur passen
Im Autorisierungs-Workflow von Newton arbeiten Data Provider parallel zur Richtlinienauswertung und nicht erst nach der Ausführung.
Der dokumentierte Ablauf lässt sich verstehen als:
Ein Transaktions-Intent wird übermittelt.
Die zugehörige Autorisierungsrichtlinie wird ausgewählt.
Die Richtlinie fordert alle benötigten kontextbezogenen Daten von konfigurierten Data Providern an.
Die Richtlinie wertet alle verfügbaren Eingaben aus.
Wenn die Anforderungen der Richtlinie erfüllt sind, wird die Anfrage an die Ausführung weitergegeben.
Diese Trennung hält die Ausführung darauf fokussiert, die genehmigten Operationen durchzuführen, während die Richtlinienauswertung dafür verantwortlich bleibt zu bestimmen, ob diese Operationen erlaubt sind.
Eine Backend-Analogie
Für Entwickler, die mit Node.js, Express oder Next.js vertraut sind, ähneln Data Provider Backend-Diensten, die eingehende Anfragen anreichern, bevor die Geschäftslogik ausgeführt wird.
Beispielsweise könnte ein API-Gateway Benutzerattribute oder organisatorische Berechtigungen abrufen, bevor es eine Anfrage an einen Anwendungsdienst weiterleitet.
Newton verfolgt eine ähnliche Architekturidee, indem es Richtlinien ermöglicht, kontextbezogene Informationen zu konsumieren, bevor die Autorisierung abgeschlossen ist.
Die Analogie trifft jedoch nicht exakt zu. Herkömmliche Backend-Erweiterungen finden normalerweise in einer zentralisierten Serverumgebung statt. In Newton beteiligen sich Data Provider an dem dokumentierten Autorisierungsrahmen des Protokolls, statt als gewöhnliche Middleware in einer Webanwendung zu agieren.
Warum das wichtig ist
Die Trennung des Abrufs kontextbezogener Daten von der Ausführung bietet mehrere praktische Vorteile.
Entwickler können Autorisierungsrichtlinien so gestalten, dass sie sich auf die Entscheidungslogik konzentrieren, statt mehrere Muster des Datenzugriffs in Smart Contracts einzubetten.
KI-Agenten profitieren, weil Autorisierungsentscheidungen anhand expliziter kontextbezogener Informationen bewertet werden können, statt auf hartkodierte Annahmen zurückzugreifen.
Unternehmenssysteme benötigen häufig Autorisierungsentscheidungen auf Basis organisatorischer Richtlinien, wodurch kontextbezogene Auswertung eine naheliegende architektonische Passform ist.
Auch Sicherheitsteams gewinnen ein klareres Verständnis darüber, welche Informationen Autorisierungsentscheidungen beeinflussen, weil die Richtlinien-Eingaben Teil eines strukturierten Auswertungsprozesses bleiben.
Unabhängige architektonische Analyse
Basierend auf der offiziellen Dokumentation leisten Data Provider einen Beitrag zu einer modularen Autorisierungsarchitektur.
Die Trennung von Datenbeschaffung, Richtlinienauswertung und Ausführung verbessert die Wartbarkeit, indem jeder architektonischen Schicht eine klar abgegrenzte Verantwortung zugewiesen wird.
Außerdem unterstützt es die Erweiterbarkeit. Neue Quellen für kontextbezogene Informationen können an der Richtlinienauswertung teilnehmen, ohne die Ausführungsschicht selbst grundsätzlich zu verändern.
Dieses geschichtete Design spiegelt ein vertrautes Prinzip aus der Softwareentwicklung wider: Trennt den Datenabruf, das Treffen von Entscheidungen und die Ausführung, sobald sich diese Anliegen unabhängig voneinander weiterentwickeln.
Fazit
Eine der zentralen Architekturideen von Newton ist, dass eine effektive Autorisierung oft von Kontext abhängt – nicht nur von Transaktionen.
Durch die Einführung von Data Providern in den Prozess der Richtlinienauswertung ermöglicht das Protokoll, dass Autorisierungsentscheidungen die in dokumentierten Richtlinien geforderte Information berücksichtigen, dabei aber eine klare Trennung zwischen Datenzugriff, Richtlinienauswertung und Ausführung beibehalten wird. Diese Architektur fördert modulare, verständliche und wartbare Autorisierungsabläufe.
Hinweis zur bezahlten Partnerschaft: Diese technische Analyse ist Teil der Newton CreatorPad-Kampagne und ist ausschließlich für eine pädagogische Diskussion gedacht.
Diskussionsfrage: Wie sollten dezentrale Systeme eine umfangreiche kontextbezogene Richtlinienauswertung mit dem Ziel in Einklang bringen, Autorisierungsabläufe modular zu halten und leicht prüfen (auditen) zu können?