Je pensais au départ que la contribution principale de @NewtonProtocol consistait à séparer l’autorisation de la logique d’application. Après avoir passé plus de temps avec l’architecture, je me suis retrouvé à me concentrer sur quelque chose de beaucoup plus petit : la décision d’associer les identifiants de politique à la configuration du PolicyClient, plutôt que de traiter la configuration comme un simple détail secondaire.
Ce mécanisme modifie la manière dont l’historique des autorisations est conservé.
Un PolicyClient fait référence à une politique Rego réutilisable tout en fournissant des paramètres d’exécution tels que des limites de dépenses, des destinataires approuvés, des restrictions juridictionnelles ou d’autres contraintes opérationnelles. La logique de la politique reste la même, mais la configuration définit l’environnement dans lequel cette logique est évaluée. Plutôt que d’intégrer ces limites dans chaque politique, Newton les transmet sous forme de données de configuration structurées lors de l’évaluation.
La partie intéressante apparaît lorsque ces frontières changent.
Plutôt que de permettre à la même identité d’autorisation de continuer, Newton génère un nouvel identifiant de politique chaque fois que la configuration de PolicyClient change. Les attestations créées sous la configuration précédente ne sont plus valides dès que le client référence le nouvel identifiant. L’autorisation reste donc liée à la configuration exacte qui l’a produite, plutôt qu’à la seule politique réutilisable elle-même.
D’un point de vue architectural, cela crée un lien plus fort entre l’approbation et le contexte. Deux applications peuvent exécuter une logique de politique identique tout en appliquant des limites opérationnelles différentes. Traiter ces environnements comme des identités d’autorisation distinctes facilite la distinction entre les approbations qui appartiennent à quelle configuration.
Mais quelque chose continuait de me tracasser.
La configuration n’est qu’une source de changement. Certaines décisions d’autorisation dépendent aussi d’informations qui existent en dehors de la blockchain. Newton y répond grâce à des PolicyData Oracles exécutés en tant que composants WASM isolés. Une entrée structurée entre dans le composant, les opérations autorisées s’exécutent dans un bac à sable, et du JSON structuré devient disponible pendant l’évaluation de la politique.
L’isolation est délibérée. L’exécution de l’oracle bloque les adresses de bouclage, les plages de réseau privé et les interfaces locales de liaison tout en limitant les requêtes HTTP à des points de terminaison publiquement accessibles. Les développeurs peuvent aussi définir des schémas JSON afin que les requêtes invalides soient rejetées avant même le début de l’exécution.
La conception modifie la frontière.
Les réponses de l’oracle introduisent une autre distinction qui a retenu mon attention. Si l’information externe ne peut pas être obtenue ou si la validation échoue, les politiques peuvent interpréter des données d’erreur structurées et refuser l’autorisation. Si, en revanche, le composant WASM lui-même ne peut pas s’exécuter correctement, l’évaluation s’arrête avec une DataProviderError au lieu de produire un résultat d’autorisation normal.
Cela ne supprime pas la confiance. Cela la déplace.
La responsabilité se déplace vers ceux qui configurent les politiques, conçoivent les composants d’oracle et décident comment les échecs doivent influencer les résultats d’autorisation. Le protocole fournit des mécanismes réutilisables, mais les applications restent responsables de choisir les périodes d’expiration, les limites opérationnelles et le comportement des politiques qui correspondent à leurs exigences.
Le même équilibre apparaît dans les attestations. Chaque autorisation inclut une valeur expireAfter, permettant aux applications d’échanger des fenêtres de validité plus courtes contre moins d’opportunités de rejeu, ou des fenêtres plus longues pour une meilleure convivialité. Le protocole offre de la flexibilité sans prescrire à quel niveau cet équilibre doit être fixé.
L’implémentation compte plus que le mécanisme.
Pour les développeurs qui construisent des systèmes autour de la vérification de sanctions, de la vérification d’identité, des contrôles de trésorerie, des opérations de stablecoins, des transferts d’actifs du monde réel ou d’agents logiciels autonomes, l’architecture change l’endroit où réside la complexité. Au lieu de répartir la logique d’autorisation dans tout le code de l’application, elle concentre la responsabilité au sein de politiques réutilisables, d’identifiants sensibles à la configuration, de fournisseurs de données isolés et d’attestations liées au temps dont la signification dépend des conditions dans lesquelles elles ont été créées.
Lier l’autorisation à des identifiants de politiques spécifiques à la configuration renforce-t-il l’intégrité à long terme de l’autorisation, ou ne fait-il que déplacer la responsabilité opérationnelle vers une autre couche ?