Erik Zhang vervollständigt das Neo-Authentifizierungstrio mit NEP-33
Neo-Mitbegründer Erik Zhang hat NEP-33 veröffentlicht, den dritten Neo-Verbesserungsvorschlag, den er innerhalb von zwei Wochen vorgelegt hat. Der Standard definiert einen URI-basierten Transportmechanismus, der es nativen Anwendungen ermöglicht, Wallet-Anwendungen zur Authentifizierung aufzurufen und so einen dreischichtigen Stapel zu vervollständigen, der standardisiert, wie sich Benutzer mit ihrem Neo-Wallet anmelden.
NEP-33 folgt NEP-20, das die kryptografischen Authentifizierungsregeln festlegte, und NEP-21, das eine einheitliche Schnittstelle für dApps zur Kommunikation mit Wallet-Anbietern definierte. Während diese beiden Standards die Authentifizierungslogik und Wallet-Funktionen handhaben, befasst sich NEP-33 mit dem Einstiegspunkt: wie eine Anwendung eine Authentifizierungsanfrage an ein Wallet weiterleitet und das Ergebnis empfängt.
Was dies ermöglicht
Vor NEP-33 gab es keine standardisierte Möglichkeit für eine mobile oder Desktop-Anwendung, eine Neo-Wallet zur Authentifizierung aufzurufen.
Jede Wallet und jede Anwendung implementierte ihr eigenes Aufruf- und Rückrufformat, was zu Fragmentierung führte. NEP-33 führt neoauth:// ein, ein benutzerdefiniertes URI-Schema, das nativen Anwendungen einen universellen „Sign in with Neo“-Einstiegspunkt bietet. Das Betriebssystem leitet die Anfrage an ein kompatibles Wallet weiter, das das Ergebnis über einen Callback-URI zurückgibt.
Entwickler, die auf Neo aufbauen, können nun die Wallet-Authentifizierung integrieren, ohne für jeden Anbieter einen Wallet-spezifischen Code schreiben zu müssen.
Darüber hinaus wurde NEP-33 unter Berücksichtigung der Vorwärtskompatibilität entwickelt. In einem Kommentar zum GitHub-Pull-Request des Vorschlags ging Zhang auf die Frage ein, ob separate URI-Schemata für verschiedene Neo-Netzwerkversionen existieren sollten:
Da die Adressformate von N3 und N4 gleich sind, besteht keine Notwendigkeit, sie zu unterscheiden. Und das ist nur ein Transportschichtprotokoll. In NEP-20 gibt es einen Netzwerkverhandlungsprozess.
Das Design hält das neoauth://-Schema netzwerkunabhängig, wobei die Netzwerkauswahl auf der NEP-20-Ebene erfolgt.
Wie NEP-33 funktioniert
Eine Anwendung erstellt einen Anforderungs-URI mithilfe des neoauth://-Schemas und bettet eine URL-codierte NEP-20-Challenge-Nutzlast und eine dApp-Kennung ein. Das Betriebssystem leitet dies an eine registrierte Wallet-Anwendung weiter, bei der es sich um ein generisches Ziel (Delegation der Wallet-Auswahl an das Betriebssystem oder den Benutzer) oder eine bestimmte Wallet-Implementierung handeln kann.
Das Wallet dekodiert und validiert die Nutzdaten, zeigt dem Benutzer die Authentifizierungsdetails (einschließlich der anfragenden Domäne) an und erfordert eine ausdrückliche Genehmigung. Wenn der Benutzer zustimmt, generiert das Wallet eine NEP-20-Antwortnutzlast und gibt sie über einen Rückruf-URI unter Verwendung des dapp://-Schemas zurück. Wenn der Benutzer die Anfrage ablehnt oder ein Fehler auftritt, gibt das Wallet über denselben Rückrufmechanismus eine strukturierte Fehlerantwort zurück.
Die gesamte Authentifizierungsüberprüfung folgt den kryptografischen Regeln von NEP-20, was bedeutet, dass die anfordernde Anwendung die zurückgegebene Signatur überprüfen muss, anstatt dem Rückruf-URI selbst als Authentifizierungsnachweis zu vertrauen.
NEP-33 definiert nicht neu, was Authentifizierung ist oder wie sie funktioniert, sondern bringt diese Fähigkeit vielmehr in den Interaktionsfluss zwischen dApps und Wallets ein.
Sicherheitsmodell
Da benutzerdefinierte URI-Schemata weder Vertraulichkeit noch Anwendungsidentität garantieren, basiert die Sicherheit von NEP-33 vollständig auf der Überprüfung der NEP-20-Signatur.
Der Standard verlangt, dass Wallets zum Schutz vor Phishing die anfordernde Domäne deutlich anzeigen, erzwingt eindeutige Einmal-Nonces mit einem empfohlenen Ablauf von fünf Minuten, um Replay-Angriffe zu verhindern, und schreibt eine ausdrückliche Zustimmung des Benutzers vor, bevor eine Signatur erstellt wird.
NEP-33 ist ausschließlich für einmalige Authentifizierungsflüsse konzipiert. Es sollte nicht zum Signieren von Transaktionen, zum Übertragen von Vermögenswerten, zum Aufrufen intelligenter Verträge oder zur sitzungsbasierten Autorisierung verwendet werden.
Die vollständige Ankündigung finden Sie unter dem folgenden Link: https://x.com/erikzhang/status/2042931327943741471