"Optional" in einem API-Schema bedeutet nicht optional in der Produktion. Das ist etwas, das jeder Web3-Entwickler lernen sollte.**
Während ich mich durch den Newton-Protocol-Authorization-Flow gearbeitet habe, ist mir eine Designentscheidung besonders aufgefallen: In dem Basis-Request-Schema ist das Feld `intent_signature` im `newt_createTask`-RPC als optional getaggt.
Das kann anfangs verwirrend sein.
Wenn es optional ist, warum schlagen dann einige Requests ohne sie fehl?
Die Antwort liegt darin, wie Newton ** generische Infrastruktur ** von ** politik-spezifischen Anforderungen ** trennt.
Der Basis-RPC ist so konzipiert, dass er eine Vielzahl unterschiedlicher Autorisierungsmodelle unterstützt. Einige Policies benötigen nur grundlegende Transaktionsdaten, andere verifizieren die Absicht des Nutzers über eine **EIP-712-Signatur**. Der gemeinsame Endpunkt benötigt das nicht – aber wenn eine Policy ` intent_signature ` referenziert oder wenn ein PolicyClient bzw. ein identity-basiertes Autorisierungs-Flow darauf angewiesen ist, dann ist die Signatur erforderlich.
Das ist eine bedeutende Architekturentscheidung.
Anstatt separate APIs für jedes Autorisierungsmodell zu erstellen, bietet Newton eine flexible Schnittstelle, die auf unterschiedliche Sicherheitsanforderungen zugeschnitten werden kann. Das macht das Protokoll erweiterbar und ermöglicht Entwicklern, auf derselben Infrastruktur alles von einfacher Automatisierung bis hin zu stark regulierten Finanz-Workflows aufzubauen.
Aber diese Flexibilität trägt eine Verantwortung für Integratoren.
Ein Frontend könnte gegen das Basisschema validieren, aber trotzdem nicht alle Felder enthalten, die die gewählte Policy benötigt. In vielen Fällen wird das Gateway die Anfrage ablehnen, bevor überhaupt die Rego-Policy ausgewertet wird, da ungültige oder leere Signaturen (wie `0x`) nicht dem erwarteten EIP-712-Signaturformat entsprechen.
Was das bedeutet: Entwickler sollten Schema-Validierung nicht als die letzte Validierungsebene betrachten.
Eine gute Integration sollte Folgendes verstehen:
✅ Die verwendete Autorisierungs-Policy.
✅ Ob diese Policy eine signierte Absicht erfordert.
✅ Fügt ein identity-basiertes Flow zusätzliche Signierungsanforderungen hinzu.
✅ Den Nutzer unterschreiben lassen, bevor die Anfrage gesendet wird
#newtonprocol @NewtonProtocol $NEWT
Während ich mich durch den Newton-Protocol-Authorization-Flow gearbeitet habe, ist mir eine Designentscheidung besonders aufgefallen: In dem Basis-Request-Schema ist das Feld `intent_signature` im `newt_createTask`-RPC als optional getaggt.
Das kann anfangs verwirrend sein.
Wenn es optional ist, warum schlagen dann einige Requests ohne sie fehl?
Die Antwort liegt darin, wie Newton ** generische Infrastruktur ** von ** politik-spezifischen Anforderungen ** trennt.
Der Basis-RPC ist so konzipiert, dass er eine Vielzahl unterschiedlicher Autorisierungsmodelle unterstützt. Einige Policies benötigen nur grundlegende Transaktionsdaten, andere verifizieren die Absicht des Nutzers über eine **EIP-712-Signatur**. Der gemeinsame Endpunkt benötigt das nicht – aber wenn eine Policy ` intent_signature ` referenziert oder wenn ein PolicyClient bzw. ein identity-basiertes Autorisierungs-Flow darauf angewiesen ist, dann ist die Signatur erforderlich.
Das ist eine bedeutende Architekturentscheidung.
Anstatt separate APIs für jedes Autorisierungsmodell zu erstellen, bietet Newton eine flexible Schnittstelle, die auf unterschiedliche Sicherheitsanforderungen zugeschnitten werden kann. Das macht das Protokoll erweiterbar und ermöglicht Entwicklern, auf derselben Infrastruktur alles von einfacher Automatisierung bis hin zu stark regulierten Finanz-Workflows aufzubauen.
Aber diese Flexibilität trägt eine Verantwortung für Integratoren.
Ein Frontend könnte gegen das Basisschema validieren, aber trotzdem nicht alle Felder enthalten, die die gewählte Policy benötigt. In vielen Fällen wird das Gateway die Anfrage ablehnen, bevor überhaupt die Rego-Policy ausgewertet wird, da ungültige oder leere Signaturen (wie `0x`) nicht dem erwarteten EIP-712-Signaturformat entsprechen.
Was das bedeutet: Entwickler sollten Schema-Validierung nicht als die letzte Validierungsebene betrachten.
Eine gute Integration sollte Folgendes verstehen:
✅ Die verwendete Autorisierungs-Policy.
✅ Ob diese Policy eine signierte Absicht erfordert.
✅ Fügt ein identity-basiertes Flow zusätzliche Signierungsanforderungen hinzu.
✅ Den Nutzer unterschreiben lassen, bevor die Anfrage gesendet wird
#newtonprocol @NewtonProtocol $NEWT