当初私は、@NewtonProtocol の主な貢献は、認可をアプリケーションロジックから切り離すことにあるのだと考えていました。アーキテクチャにより多くの時間を費やすうちに、私はもっと小さな点に注目するようになりました。それは、設定を二次的な詳細として扱うのではなく、ポリシー識別子を PolicyClient の設定に結び付けるという判断です。
この仕組みにより、認可履歴がどのように保持されるかが変わります。
PolicyClient は、支出限度、承認済みの受取人、管轄の制約、またはその他の運用上の制約などの実行時パラメータを渡しながら、再利用可能な Rego ポリシーを参照します。ポリシーのロジック自体は同じままですが、そのロジックが評価される環境は、構成（コンフィギュレーション）によって定義されます。これらの境界を毎回のポリシーに埋め込む代わりに、Newton は評価時にそれらを構造化された設定データとして渡します。
面白いのは、その境界が変わったときです。
同じ認可アイデンティティが継続して使われるのではなく、Newtonは、PolicyClientの設定が変更されるたびに新しいポリシー識別子を生成します。前の設定のもとで作成されたアテステーションは、クライアントが新しい識別子を参照した時点で無効になります。そのため、認可は単に再利用可能なポリシーそのものに紐づくのではなく、それを生成した「正確な設定」に結び付いたままになります。
アーキテクチャの観点から見ると、これは承認と文脈の結びつきをより強くします。同一のポリシーロジックを実行していても、異なる運用上の制限を適用することがあり得ます。これらの環境を別個の認可アイデンティティとして扱うことで、どの承認がどの設定に属するのかを区別しやすくなります。
しかし、気になり続けることがありました。
変更の原因は設定だけではありません。ある認可判断は、ブロックチェーンの外に存在する情報にも依存します。Newtonは、分離されたWASMコンポーネントとして動作するPolicyData Oraclesによってそれに対応します。構造化された入力がコンポーネントに渡され、許可された操作がサンドボックス内で実行され、ポリシー評価の最中に構造化JSONが利用可能になります。
分離は意図的です。オラクルの実行はループバックアドレス、プライベートネットワーク範囲、リンクローカルインターフェースをブロックし、HTTPリクエストは公開的に到達可能なエンドポイントに限定します。開発者はまた、JSONスキーマを定義して、無効なリクエストが実行される前に拒否できるようにすることもできます。
設計が境界を変えるのです。
オラクルの応答は、もう一つの区別を生み、私の注意を引きました。外部情報を取得できない、または検証に失敗した場合、ポリシーは構造化されたエラーデータを解釈して認可を拒否できます。WASMコンポーネント自体が正常に実行できない場合は、通常の認可結果ではなくDataProviderErrorで評価が停止します。
それは信頼を取り除くのではありません。信頼の置き場所を変えるのです。
責任は、ポリシーを設定する側、オラクル・コンポーネントを設計する側、そして失敗が認可結果にどう影響すべきかを決める側へと移ります。プロトコルは再利用可能な仕組みを提供しますが、アプリケーション側には、自身の要件に合う有効期限、運用上の境界、そしてポリシーの挙動を選ぶ責任が残ります。
同じバランスがアテステーションにも現れます。すべての認可にはexpireAfter値が含まれており、アプリケーションは、リプレイ機会を減らすために有効期間を短くするか、利便性を高めるために長くするか、その両者の間で柔軟に選べます。プロトコルは、そのバランスをどこに設定するかは規定せず、柔軟性を提供します。
仕組みよりも実装が重要です。
制裁スクリーニング、本人確認、歳入（トレジャリー）管理、ステーブルコインの運用、現実世界の資産の移転、自律型ソフトウェアエージェントなどの周辺でシステムを構築する開発者にとって、アーキテクチャが変えるのは複雑性が存在する場所です。アプリケーションコード全体に認可ロジックを分散させるのではなく、責任を再利用可能なポリシー、設定を意識した識別子、分離されたデータプロバイダ、そしてそれが作成された条件に意味が依存する時間制限付きのアテステーションの内部へ集中させます。
認可を設定固有のポリシー識別子に結び付けることで、長期的な認可の整合性は強まるのか。それとも、単に運用上の責任を別のレイヤーへ移すだけなのか。