Erik Zhang completa el trío de autenticación Neo con NEP-33
El cofundador de Neo, Erik Zhang, publicó NEP-33, la tercera propuesta de mejora de Neo que presentó en dos semanas. El estándar define un mecanismo de transporte basado en URI que permite a las aplicaciones nativas invocar aplicaciones de billetera para autenticación, completando una pila de tres capas que estandariza cómo los usuarios inician sesión con su billetera Neo.
NEP-33 sigue a NEP-20, que estableció las reglas de autenticación criptográfica, y NEP-21, que definió una interfaz unificada para que las dApps se comuniquen con los proveedores de billeteras. Mientras que esos dos estándares manejan la lógica de autenticación y las capacidades de billetera, NEP-33 aborda el punto de entrada: cómo una aplicación entrega una solicitud de autenticación a una billetera y recibe el resultado.
Lo que esto permite
Antes de NEP-33, no existía una forma estandarizada para que una aplicación móvil o de escritorio invocara una billetera Neo para autenticación.
Cada billetera y aplicación implementó su propio formato de invocación y devolución de llamada, creando fragmentación. NEP-33 presenta neoauth://, un esquema de URI personalizado que brinda a las aplicaciones nativas un punto de entrada universal para "iniciar sesión con Neo". El sistema operativo enruta la solicitud a una billetera compatible, que devuelve el resultado a través de un URI de devolución de llamada.
Los desarrolladores que utilizan Neo ahora pueden integrar la autenticación de billetera sin escribir código específico de billetera para cada proveedor.
Además, NEP-33 se ha diseñado teniendo en cuenta la compatibilidad futura. En un comentario sobre la solicitud de extracción de GitHub de la propuesta, Zhang abordó una pregunta sobre si deberían existir esquemas de URI separados para diferentes versiones de la red Neo:
Dado que los formatos de dirección de N3 y N4 son los mismos, no es necesario distinguirlos. Y este es sólo un protocolo de capa de transporte. Hay un proceso de negociación de red en NEP-20.
El diseño mantiene el esquema neoauth:// independiente de la red, con la selección de red manejada en la capa NEP-20.
Cómo funciona NEP-33
Una aplicación construye un URI de solicitud utilizando el esquema neoauth://, incorporando una carga útil de desafío NEP-20 codificada en URL y un identificador de dApp. El sistema operativo enruta esto a una aplicación de billetera registrada, que puede ser un objetivo genérico (delegar la selección de billetera al sistema operativo o al usuario) o una implementación de billetera específica.
La billetera decodifica y valida la carga útil, muestra los detalles de autenticación (incluido el dominio solicitante) al usuario y requiere aprobación explícita. Si el usuario lo aprueba, la billetera genera una carga útil de respuesta NEP-20 y la devuelve a través de un URI de devolución de llamada utilizando el esquema dapp://. Si el usuario rechaza la solicitud o se produce un error, la billetera devuelve una respuesta de error estructurada a través del mismo mecanismo de devolución de llamada.
Toda verificación de autenticación sigue las reglas criptográficas de NEP-20, lo que significa que la aplicación solicitante debe verificar la firma devuelta en lugar de confiar en el URI de devolución de llamada como prueba de autenticación.
NEP-33 no redefine qué es la autenticación o cómo funciona, sino que incorpora esa capacidad al flujo de interacción entre dApps y billeteras.
Modelo de seguridad
Debido a que los esquemas de URI personalizados no garantizan la confidencialidad ni la identidad de la aplicación, la seguridad de NEP-33 depende completamente de la verificación de firmas de NEP-20.
El estándar requiere que las billeteras muestren claramente el dominio solicitante para proteger contra el phishing, impone nonces únicos de un solo uso con una caducidad recomendada de cinco minutos para evitar ataques de repetición y exige la aprobación explícita del usuario antes de que se produzca cualquier firma.
NEP-33 está diseñado exclusivamente para flujos de autenticación únicos. No debe utilizarse para la firma de transacciones, transferencias de activos, invocación de contratos inteligentes o autorización basada en sesiones.
El anuncio completo se puede encontrar en el siguiente enlace: https://x.com/erikzhang/status/2042931327943741471