Erik Zhang complète le trio d'authentification Neo avec NEP-33

Le co-fondateur de Neo, Erik Zhang, a publié NEP-33, la troisième proposition d'amélioration de Neo qu'il a présentée en deux semaines. La norme définit un mécanisme de transport basé sur l'URI qui permet aux applications natives d'invoquer des applications de portefeuille pour l'authentification, complétant ainsi une pile à trois couches qui standardise la façon dont les utilisateurs se connectent avec leur portefeuille Neo.

NEP-33 fait suite au NEP-20, qui a établi les règles d'authentification cryptographique, et au NEP-21, qui a défini une interface unifiée permettant aux dApps de communiquer avec les fournisseurs de portefeuilles. Là où ces deux normes gèrent la logique d'authentification et les capacités du portefeuille, NEP-33 aborde le point d'entrée : comment une application transmet une demande d'authentification à un portefeuille et reçoit le résultat.

Ce que cela permet

Avant NEP-33, il n'existait aucun moyen standardisé permettant à une application mobile ou de bureau d'invoquer un portefeuille Neo pour l'authentification.

Chaque portefeuille et application a implémenté son propre format d'invocation et de rappel, créant une fragmentation. NEP-33 introduit neauth://, un schéma d'URI personnalisé qui donne aux applications natives un point d'entrée universel « Connectez-vous avec Neo ». Le système d'exploitation achemine la demande vers un portefeuille compatible, qui renvoie le résultat via un URI de rappel.

Les développeurs s'appuyant sur Neo peuvent désormais intégrer l'authentification du portefeuille sans écrire de code spécifique au portefeuille pour chaque fournisseur.

De plus, le NEP-33 a été conçu dans un souci de compatibilité ascendante. Dans un commentaire sur la demande d'extraction GitHub de la proposition, Zhang a répondu à la question de savoir si des schémas d'URI distincts devraient exister pour les différentes versions du réseau Neo :

Puisque les formats d’adresse de N3 et N4 sont identiques, il n’est pas nécessaire de les distinguer. Et ce n'est qu'un protocole de couche transport. Il existe un processus de négociation de réseau dans NEP-20.

La conception conserve le schéma neauth:// indépendant du réseau, la sélection du réseau étant gérée au niveau de la couche NEP-20.

Comment fonctionne le NEP-33

Une application construit un URI de requête à l'aide du schéma neauth://, intégrant une charge utile de défi NEP-20 codée en URL et un identifiant dApp. Le système d'exploitation achemine cela vers une application de portefeuille enregistrée, qui peut être une cible générique (déléguant la sélection du portefeuille au système d'exploitation ou à l'utilisateur) ou une implémentation de portefeuille spécifique.

Le portefeuille décode et valide la charge utile, affiche les détails d'authentification (y compris le domaine demandeur) à l'utilisateur et nécessite une approbation explicite. Si l'utilisateur approuve, le portefeuille génère une charge utile de réponse NEP-20 et la renvoie via un URI de rappel en utilisant le schéma dapp://. Si l'utilisateur rejette la demande ou qu'une erreur se produit, le portefeuille renvoie une réponse d'erreur structurée via le même mécanisme de rappel.

Toutes les vérifications d'authentification suivent les règles cryptographiques du NEP-20, ce qui signifie que l'application requérante doit vérifier la signature renvoyée plutôt que de faire confiance à l'URI de rappel lui-même comme preuve d'authentification.

NEP-33 ne redéfinit pas ce qu'est l'authentification ni comment elle fonctionne, mais intègre plutôt cette capacité dans le flux d'interaction entre les dApps et les portefeuilles.

Modèle de sécurité

Étant donné que les schémas d'URI personnalisés ne garantissent pas la confidentialité ou l'identité de l'application, la sécurité du NEP-33 repose entièrement sur la vérification de la signature NEP-20.

La norme exige que les portefeuilles affichent clairement le domaine demandeur pour se protéger contre le phishing, impose des noms occasionnels uniques à usage unique avec une expiration recommandée de cinq minutes pour empêcher les attaques par réexécution et exige l'approbation explicite de l'utilisateur avant qu'une signature ne soit produite.

NEP-33 est conçu exclusivement pour les flux d'authentification ponctuels. Il ne doit pas être utilisé pour la signature de transactions, les transferts d'actifs, l'invocation de contrats intelligents ou l'autorisation basée sur la session.

L'annonce complète peut être consultée sur le lien ci-dessous : https://x.com/erikzhang/status/2042931327943741471