Saltar al contenido principal

De contraseñas a pruebas portátiles: Guía 2025 para constructores sobre identidad Web3

· 11 min de lectura
Dora Noda
Dora Noda
Software Engineer

La mayoría de las aplicaciones todavía anclan la identidad a nombres de usuario, contraseñas y bases de datos centralizadas. Ese modelo es frágil (filtraciones), filtrante (reventa de datos) y engorroso (repetidos KYC interminables). La nueva pila que surge alrededor de los identificadores descentralizados (DID), credenciales verificables (VC) y attestaciones apunta a un futuro diferente: los usuarios llevan pruebas criptográficas de hechos sobre sí mismos y revelan solo lo necesario, ni más ni menos.

Esta publicación destila el panorama y ofrece un plano práctico que puedes lanzar hoy.

El cambio: de cuentas a credenciales​

El núcleo de esta nueva pila de identidad se construye sobre dos estándares fundacionales de la W3C que cambian fundamentalmente la forma en que manejamos los datos de los usuarios.

  • Identificadores descentralizados (DIDs): Son identificadores controlados por el usuario que no requieren un registro central como un sistema de nombres de dominio. Piensa en un DID como una dirección permanente y auto‑propiedad para la identidad. Un DID se resuelve a un “documento DID” firmado que contiene claves públicas y puntos de servicio, permitiendo autenticación segura y descentralizada. El estándar v1.0 se convirtió en una Recomendación oficial de la W3C el 19 de julio de 2022, marcando un hito importante para el ecosistema.
  • Credenciales verificables (VCs): Es un formato digital a prueba de manipulaciones para expresar afirmaciones, como “la edad es mayor de 18”, “posee un diploma de la Universidad X” o “ha pasado una verificación KYC”. El Modelo de datos VC 2.0 se convirtió en una Recomendación de la W3C el 15 de mayo de 2025, consolidando una base moderna para cómo se emiten y verifican estas credenciales.

¿Qué cambia para los desarrolladores? El cambio es profundo. En lugar de almacenar información de identificación personal sensible (PII) en tu base de datos, verificas pruebas criptográficas suministradas por la billetera del usuario. Puedes solicitar solo la pieza específica de información que necesitas (por ejemplo, residencia en un país concreto) sin ver el documento subyacente, gracias a primitivas poderosas como la divulgación selectiva.

Dónde se encuentra con los inicios de sesión que ya usas​

Este nuevo mundo no requiere abandonar experiencias de inicio de sesión familiares. En su lugar, las complementa.

  • Passkeys / WebAuthn: Es tu opción principal para autenticación resistente al phishing. Las passkeys son credenciales FIDO vinculadas a un dispositivo o biométrica (como Face ID o huella), y ahora son compatibles con todos los navegadores y sistemas operativos principales. Ofrecen una experiencia de inicio de sesión sin contraseña y sin fricciones para tu app o billetera.
  • Sign‑In with Ethereum (SIWE / EIP‑4361): Este estándar permite que un usuario demuestre el control de una dirección de cadena de bloques y la vincule a una sesión de aplicación. Funciona mediante un mensaje simple firmado con nonce, creando un puente limpio entre sesiones Web2 tradicionales y control Web3.

La mejor práctica es usarlos juntos: implementa passkeys para inicios de sesión cotidianos y ofrece SIWE para flujos vinculados a billetera donde el usuario necesite autorizar una acción cripto‑nativa.

Los rieles para emitir y comprobar credenciales​

Para que las credenciales sean útiles, necesitamos formas estandarizadas de emitirlas a los usuarios y de que los usuarios las presenten a las apps. La OpenID Foundation provee los dos protocolos clave para esto.

  • Emisión: OpenID for Verifiable Credential Issuance (OID4VCI) define una API protegida por OAuth para obtener credenciales de emisores (como una agencia gubernamental o un proveedor de KYC) dentro de la billetera digital del usuario. Está diseñada para ser flexible, soportando múltiples formatos de credencial.
  • Presentación: OpenID for Verifiable Presentations (OID4VP) estandariza cómo tu aplicación hace una “solicitud de prueba” y cómo la billetera del usuario responde. Esto puede ocurrir mediante redirecciones OAuth clásicas o a través de APIs modernas del navegador.

Al construir, encontrarás algunos formatos clave de credencial diseñados para diferentes ecosistemas y casos de uso:

  • W3C VC con suites de Integridad de Datos (JSON‑LD): A menudo emparejado con criptografía BBS+ para habilitar divulgación selectiva potente.
  • VC‑JOSE‑COSE y SD‑JWT VC (IETF): Estos formatos están construidos para ecosistemas basados en JWT y CBOR, también con capacidades fuertes de divulgación selectiva.

Afortunadamente, la interoperabilidad está mejorando rápidamente. Perfiles como OpenID4VC High Assurance están ayudando a reducir las opciones técnicas, haciendo que las integraciones entre proveedores sean mucho más sensatas para los desarrolladores.

Métodos DID: eligiendo el esquema de dirección correcto​

Un DID es solo un identificador; un “método DID” especifica cómo se ancla a una raíz de confianza. Querrás soportar un par de los más comunes.

  • did:web: Este método respalda un DID con un dominio que controlas. Es increíblemente fácil de desplegar y es una opción fantástica para empresas, emisores y organizaciones que quieran aprovechar su infraestructura web existente como ancla de confianza.
  • did:pkh: Este método deriva un DID directamente de una dirección de cadena de bloques (por ejemplo, una dirección Ethereum). Es muy útil cuando tu base de usuarios ya posee billeteras cripto y deseas vincular su identidad a activos on‑chain.

Regla práctica: Soporta al menos dos métodos — did:web para organizaciones y did:pkh para usuarios individuales. Usa una biblioteca estándar de resolvedor DID para manejar la búsqueda y consulta los registros oficiales para evaluar la seguridad, persistencia y gobernanza de cualquier método nuevo que consideres añadir.

Bloques de construcción útiles que puedes conectar​

Más allá de los estándares centrales, varias herramientas pueden potenciar tu pila de identidad.

  • ENS (Ethereum Name Service): Proporciona nombres legibles por humanos (tuNombre.eth) que pueden mapear a direcciones de cadena de bloques y DIDs. Es una herramienta invaluable para mejorar la experiencia del usuario, reducir errores y ofrecer una capa de perfil sencilla.
  • Attestations: Son “hechos verificables sobre cualquier cosa” que pueden registrarse on‑chain o off‑chain. El Ethereum Attestation Service (EAS), por ejemplo, brinda una base robusta para construir grafos de reputación y confianza sin almacenar nunca PII en un ledger público.

Vientos regulatorios que debes seguir​

La regulación a menudo se ve como un obstáculo, pero en este espacio es un acelerador masivo. El Marco de Identidad Digital de la UE (eIDAS 2.0), adoptado oficialmente como Reglamento UE 2024/1183 el 20 de mayo de 2024, es el desarrollo más significativo. Obliga a todos los Estados miembros de la UE a ofrecer a sus ciudadanos una Billetera Digital de Identidad de la UE (EUDI) gratuita. Con regulaciones de implementación publicadas el 7 de mayo de 2025, esto es una señal poderosa para la adopción de credenciales basadas en billetera tanto en servicios públicos como privados en Europa.

Incluso si no operas en la UE, espera que la Billetera EUDI y sus protocolos subyacentes moldeen las expectativas de los usuarios y fomenten la adopción global de billeteras.

Patrones de diseño que funcionan en producción (2025)​

  • Primero sin contraseña, billeteras opcionales: Usa passkeys por defecto para iniciar sesión. Es seguro, simple y familiar. Introduce SIWE solo cuando los usuarios necesiten realizar una acción vinculada a cripto, como acuñar un NFT o recibir un pago.
  • Pide pruebas, no documentos: Sustituye las engorrosas cargas de documentos por una solicitud clara de prueba VC usando OID4VP. En lugar de pedir una licencia de conducir, solicita una prueba de “edad mayor de 18” o “residencia en país X”. Acepta credenciales que soporten divulgación selectiva, como las que usan BBS+ o SD‑JWT.
  • Mantén PII fuera de tus servidores: Cuando un usuario prueba algo, registra una attestation o un resultado de verificación de corta duración, no la credencial cruda. Las attestaciones on‑chain son una forma poderosa de crear un registro auditable — “Usuario Y pasó KYC con Emisor Z en fecha D” — sin almacenar datos personales.
  • Permite que las organizaciones sean emisores con did:web: Empresas, universidades y otras organizaciones ya controlan sus dominios. Permíteles firmar credenciales como emisores usando did:web, gestionando sus claves criptográficas bajo sus modelos de gobernanza web existentes.
  • Usa ENS para nombres, no para identidad: Trata ENS como un alias amigable y puntero de perfil. Es genial para UX, pero mantiene las reclamaciones de identidad autoritativas dentro de credenciales y attestaciones.

Arquitectura de partida​

Aquí tienes un plano para un sistema de identidad moderno basado en credenciales:

  • Autenticación
    • Inicio de sesión predeterminado: Passkeys (FIDO/WebAuthn).
    • Sesiones vinculadas a cripto: Sign‑In with Ethereum (SIWE) para acciones basadas en billetera.
  • Credenciales
    • Emisión: Integra con endpoints OID4VCI de tus emisores elegidos (p. ej., un proveedor de KYC, una universidad).
    • Presentación: Dispara solicitudes de prueba OID4VP desde tu app web o nativa. Prepárate para aceptar tanto W3C VCs (con BBS+) como VC SD‑JWT.
  • Resolución y confianza
    • Resolvedor DID: Usa una biblioteca que soporte al menos did:web y did:pkh. Mantén una lista blanca de DIDs emisores de confianza para evitar suplantaciones.
  • Attestaciones y reputación
    • Registros duraderos: Cuando necesites una señal auditable de una verificación, crea una attestation que contenga un hash, el DID del emisor y una marca de tiempo, en lugar de almacenar la afirmación completa.
  • Almacenamiento y privacidad
    • Minimalismo: Reduce drásticamente el PII que almacenas del lado del servidor. Encripta todo en reposo y define políticas estrictas de tiempo de vida (TTL). Prefiere pruebas efímeras y apóyate fuertemente en pruebas de conocimiento cero o divulgación selectiva.

Lecciones de UX aprendidas​

  • Empieza invisible: Para la mayoría de los usuarios, la mejor billetera es la que no tienen que pensar. Usa passkeys para manejar el inicio de sesión sin fricciones y muestra interacciones de billetera solo cuando sea absolutamente necesario.
  • Divulgación progresiva: No pidas todo de una vez. Solicita la prueba mínima que desbloquee el objetivo inmediato del usuario. Con divulgación selectiva, no necesitas su documento completo para verificar un hecho.
  • La recuperación de claves importa: Una credencial vinculada a una sola clave de dispositivo es una vulnerabilidad. Planifica la re‑emisión y la portabilidad entre dispositivos desde el primer día. Esta es una razón clave por la que los perfiles modernos adoptan formatos como SD‑JWT VC y vinculaciones basadas en reclamaciones.
  • Los alias legibles ayudan: Un nombre ENS es mucho menos intimidante que una larga dirección hexadecimal. Reduce errores de usuario y añade contexto reconocible, aunque la verdadera autoridad viva en las credenciales subyacentes.

Qué lanzar el próximo trimestre: hoja de ruta pragmática​

  • Semanas 1–2:
    • Añade passkeys a tu flujo principal de inicio de sesión.
    • Protege todas las acciones cripto‑nativas con una verificación SIWE.
  • Semanas 3–6:
    • Pilota una simple restricción por edad o región usando una solicitud OID4VP.
    • Acepta credenciales VC 2.0 con divulgación selectiva (BBS+ o SD‑JWT VC).
    • Comienza a crear attestations para eventos “verificación aprobada” en lugar de registrar PII.
  • Semanas 7–10:
    • Incorpora a un emisor partner (p. ej., tu proveedor de KYC) usando did:web e implementa una lista blanca de DIDs.
    • Ofrece vinculación de nombre ENS en los perfiles de usuario para mejorar la UX de direcciones.
  • Semanas 11–12:
    • Modela amenazas en tus flujos de presentación y revocación. Añade telemetría para modos de falla comunes (credencial expirada, emisor no confiable).
    • Publica una postura de privacidad clara explicando exactamente qué solicitas, por qué, cuánto tiempo lo retienes y cómo los usuarios pueden auditarlo.

Qué está cambiando rápido (mantente al tanto)​

  • Despliegues de la Billetera EUDI de la UE: La implementación y pruebas de conformidad de estas billeteras moldearán enormemente las capacidades y la UX de verificación a nivel global.
  • Perfiles OpenID4VC: La interoperabilidad entre emisores, billeteras y verificadores mejora constantemente gracias a nuevos perfiles y suites de pruebas.
  • Criptosuites de divulgación selectiva: Bibliotecas y guías para BBS+ y SD‑JWT VC maduran rápidamente, facilitando su adopción.

Principios para construir​

  • Demuestra, no almacenes: Prioriza la verificación de afirmaciones sobre el almacenamiento de PII cruda.
  • Interoperabilidad por defecto: Soporta múltiples formatos de credencial y métodos DID desde el primer día para preparar tu pila al futuro.
  • Minimiza y divulga: Pide la menor reclamación posible. Sé transparente con los usuarios sobre qué verificas y por qué.
  • Haz que la recuperación sea sencilla: Planifica la pérdida de dispositivos y la rotación de emisores. Evita vinculaciones de claves frágiles que dejen a los usuarios atrapados.

Si construyes plataformas fintech, sociales o para creadores, la identidad primero‑credencial ya no es una apuesta futura: es el camino más corto hacia menor riesgo, onboarding fluido e interoperabilidad global.

Share on Twitter