Ein kleines Detail in der Policy-Konfiguration von Newton hat komplett verändert, wie ich über den Integrations-Flow denke.
Beim Durcharbeiten der Dokumentation habe ich etwas erkannt, das nicht sofort ersichtlich ist.
Nur weil einer Policy-Vertragsadresse ein Wert zugewiesen wurde, heißt das noch lange nicht, dass der Kunde tatsächlich bereit ist, Attestierungen zu validieren.
Zunächst habe ich diese beiden Ideen für dasselbe gehalten. Wenn der Kunde bereits weiß, mit welchem Policy-Vertrag er kommunizieren soll, wirkt es so, als wäre das Schwierige bereits erledigt.
Wie sich herausstellt, ist das nur die halbe Prozedur.
Das Zuweisen der Policy-Adresse teilt dem Client lediglich mit, wo der Policy-Vertrag bereitgestellt ist. Es erstellt oder registriert nicht die Policy-Konfiguration, auf die die Validierung angewiesen ist.
Diese Registrierung passiert separat über `setPolicy()` (oder intern über setPolicy, das die `policyId` zurückgibt).
Ohne diesen Schritt hat der Client immer noch eine `policyId` von 0.
Und genau hier wird es interessant.
Jede Newton-Attestation trägt eine Policy-ID, und während der Validierung prüft Newton, ob die Policy-ID der Attestation mit derjenigen übereinstimmt, die für den Client registriert wurde. Wenn keine Policy registriert wurde, kann dieser Vergleich niemals erfolgreich sein—unabhängig davon, ob die Policy-Adresse selbst perfekt gültig aussieht.
Was ich besonders interessant fand, ist, dass das nicht die Art von Fehler ist, die eine Sicherheitslücke offenlegt.
Es ist fast das Gegenteil.
Der Vertrag kann erfolgreich bereitgestellt werden.
Die Policy-Adresse kann scheinbar korrekt onchain konfiguriert sein.
Alles kann bei einer kurzen Prüfung gesund wirken.
Und jede Funktion, die von der Newton-Attestation-Validierung abhängt, kann dann keine gültigen Attestationen akzeptieren, weil die erforderliche Policy-Konfiguration nie registriert wurde.
Die Unterscheidung ist subtil, aber wichtig.
Eine Policy-Adresse beantwortet nur, wo sich der Policy-Vertrag befindet.
Eine `policyId` gibt an, welche registrierte Policy-Konfiguration der Client voraussichtlich durchsetzen soll.
Das sind zwei verschiedene Zustandsbereiche.
Ich mag das Design tatsächlich, weil es einen expliziten Aktivierungsschritt einführt, statt eine Adresszuweisung automatisch als vollständig konfigurierte Policy zu behandeln.
Der Kompromiss ist jedoch, dass es möglich ist, eine Bereitstellung zu erhalten, die vollständig aussieht, aber für jeden attestierungs-geschützten Workflow funktional unvollständig ist.
Einer dieser Integrationsdetails, die man leicht übersieht, bis geschützte Transaktionen anfangen zu scheitern.
Mal gespannt, was andere denken:
Ist das Trennen der Policy-Adresszuweisung von der Policy-Registrierung ein saubereres Sicherheitsmodell, oder macht es unvollständige Bereitstellungen bei der Integration schwerer zu erkennen?