Una credencial verificable solo aporta valor cuando resuelve una decisión de confianza en un contexto real. No basta con emitirla correctamente: tiene que ser comprensible para quien la recibe, útil para quien la presenta y verificable para quien necesita confiar en ese dato.
SSI · Credenciales verificables · EUDIW · eIDAS2 · Business Wallet · Interoperabilidad
El reto de SSI no es solo emitir credenciales, sino diseñar experiencias donde personas, organizaciones y sistemas puedan confiar, compartir y verificar datos de forma útil.
En los últimos años, las credenciales verificables, las wallets digitales y los modelos SSI han pasado de ser un tema de nicho a ocupar un lugar central en muchas conversaciones sobre identidad digital. La evolución del marco europeo, con eIDAS2, EUDI Wallet y el ARF, ha acelerado todavía más esa conversación. Pero para mí, el reto sigue estando en el mismo sitio: convertir un modelo técnico potente en experiencias que puedan entenderse, adoptarse y usarse en contextos reales.
Emitir una credencial verificable puede ser técnicamente complejo, pero no es suficiente. La pregunta importante no es solo si una credencial se puede emitir, almacenar o verificar. La pregunta es qué problema resuelve, qué dato necesita ser confiable, quién debe presentarlo, quién debe verificarlo, en qué momento del proceso y con qué consecuencias.
Ahí es donde el enfoque de producto se vuelve clave. Porque SSI no es únicamente una arquitectura de identidad. Es un cambio de paradigma en la forma en que personas, organizaciones y sistemas comparten datos. Y ese cambio no siempre es intuitivo para un ciudadano, para una empresa o para una entidad que necesita operar con garantías.
El valor de una credencial verificable no está en que exista, sino en que encaje en una decisión de confianza.
Uno de los errores más habituales al trabajar con credenciales verificables es pensar que el problema termina cuando la credencial ha sido emitida correctamente. Desde una perspectiva técnica, puede parecer un hito importante: hay un issuer, un holder, una wallet, una credential, una proof y un verifier. Pero desde el punto de vista del producto, ahí empieza otra parte igual de importante: conseguir que todo eso tenga sentido para quienes participan en el proceso.
El paradigma SSI cambia la forma de compartir información. En modelos tradicionales, el ciudadano muchas veces entrega documentos completos, rellena formularios, sube archivos o depende de comprobaciones manuales. En un modelo basado en credenciales verificables, la lógica cambia: la persona puede custodiar atributos, presentar pruebas, compartir solo determinada información y operar con mayor control sobre sus datos. Esto tiene un valor enorme, pero también introduce una complejidad nueva.
Para muchas personas, una wallet puede convertirse fácilmente en un cajón de documentos digitales. Algo donde se guardan credenciales, certificados o atributos, pero sin una comprensión clara de qué significan, cuándo deben usarse, qué datos contienen o qué implica presentarlos. Si la experiencia no acompaña, el ciudadano puede terminar aceptando, compartiendo o rechazando información sin entender del todo la acción que está realizando.
También puede ocurrir lo contrario: que el caso de uso esté perfectamente construido en una demo, pero no encaje en un proceso real. Una prueba de emisión y verificación puede funcionar en laboratorio, pero fallar cuando aparecen roles, permisos, excepciones, revocaciones, expiraciones, representación organizacional, soporte, onboarding, sistemas heredados o necesidad de interoperar con distintos marcos de confianza.
Otro error frecuente es utilizar blockchain como sinónimo de SSI. No son lo mismo. SSI puede apoyarse en distintos mecanismos de confianza, y una red blockchain puede formar parte de determinados modelos, pero no define por sí sola la utilidad de una credencial verificable. El valor está en el flujo de emisión, custodia, presentación y verificación; en el marco de confianza que lo sostiene; y en la capacidad de integrarlo en procesos donde exista una necesidad real de verificar información.
El reto, por tanto, no es solo técnico. Es de adopción, de experiencia, de confianza y de producto.
Antes de diseñar una solución basada en SSI, hay que entender qué relación de confianza se quiere resolver. Una credencial no es un objeto aislado: forma parte de un flujo donde alguien acredita algo, alguien lo custodia o presenta, y alguien necesita verificarlo para tomar una decisión.
Una credencial verificable tiene sentido cuando permite confiar en un dato sin depender de procesos manuales, documentos estáticos o comprobaciones poco trazables. Puede servir para demostrar una condición, una autorización, una cualificación, una pertenencia, una elegibilidad o una representación. Pero su utilidad aparece cuando esa prueba reduce fricción, aumenta confianza o permite tomar una decisión con mayor seguridad.
Una wallet debe ayudar al ciudadano a entender qué credenciales tiene, quién las ha emitido, qué datos contienen y qué ocurre cuando decide presentarlas. La experiencia debe hacer comprensible el consentimiento: qué se comparte, con quién, para qué y durante cuánto tiempo. Automatizar parte del proceso puede ser útil, pero siempre debe mantenerse una acción explícita y comprensible cuando se comparten datos relevantes.
SSI introduce conceptos que no siempre son evidentes fuera del nicho técnico: issuer, holder, verifier, DID, proof, revocation, trust framework, selective disclosure o verifiable presentation. El reto de UX y producto está en traducir esos conceptos en acciones claras: recibir, revisar, guardar, presentar, verificar, revocar, renovar o delegar. No se trata de ocultar la complejidad, sino de hacerla operable.
No es lo mismo diseñar una Holder Wallet para ciudadanos que una Business Wallet para organizaciones. En el ámbito enterprise aparecen necesidades adicionales: identidad organizacional, atributos corporativos, representación, permisos, delegación, trazabilidad interna y actuación en nombre de una entidad. La experiencia debe contemplar no solo quién eres, sino en calidad de qué actúas y con qué autoridad.
Cuando trabajo en soluciones de identidad digital verificable, intento empezar por el caso de uso, no por la credencial. La primera pregunta no es qué estándar vamos a utilizar, sino qué dato necesita ser confiable y qué decisión depende de verificarlo.
A partir de ahí, es necesario mapear los actores del flujo. Quién emite la credencial, quién la recibe, quién la custodia, quién la presenta y quién la verifica. También hay que entender si hablamos de una persona física, una organización, un representante o un sistema que necesita operar dentro de un marco de confianza. Esta diferencia cambia completamente la experiencia y la lógica funcional.
Después viene la conversación técnica. No se puede diseñar una buena experiencia SSI sin hablar con el equipo técnico sobre viabilidad, estándares, integraciones, formatos, protocolos, revocación, expiración, confianza, seguridad y restricciones del ecosistema. eIDAS2, EUDI Wallet y el ARF son referencias importantes porque ayudan a ordenar un marco común, pero no todas las wallets ni todos los casos de uso son estrictamente EUDI Wallet. Aun así, estar alineados con ese marco importa: por interoperabilidad, por expectativas de mercado, por evolución regulatoria y por la necesidad de no construir soluciones aisladas.
Ese trabajo técnico después tiene que traducirse a UX. Un ciudadano no debería necesitar entender el ARF para saber qué está compartiendo. Una organización no debería tener que interpretar conceptos criptográficos para operar con una Business Wallet. Un verificador no debería enfrentarse a un flujo opaco para saber si una credencial es válida, está vigente y procede de una entidad confiable.
Para mí, el reto está en automatizar todo lo que pueda reducir fricción sin eliminar control. Si el sistema puede reconocer una credencial, interpretar su estado, validar su emisor o preparar una presentación, perfecto. Pero cuando hay intercambio de datos personales, autorización o presentación de atributos relevantes, el consentimiento debe ser explícito, entendible y proporcionado.
También hay que diseñar el contexto de error. Qué ocurre si una credencial está revocada, si ha caducado, si el verifier no la acepta, si falta un atributo, si la wallet no es compatible o si la organización no tiene autorización para actuar. Muchos prototipos funcionan bien en el happy path, pero los productos reales se sostienen en cómo resuelven las excepciones. Por eso, aterrizar SSI en producto exige una mirada híbrida: entender el estándar, hablar con tecnología, comprender el proceso de negocio y diseñar una experiencia que no exponga al ciudadano o a la organización a una complejidad innecesaria.
Las credenciales verificables tienen un potencial enorme para transformar cómo compartimos y verificamos información. Pueden reducir fricción, mejorar privacidad, facilitar interoperabilidad, reforzar confianza y abrir nuevos escenarios para ciudadanos y organizaciones. Pero ese potencial solo se materializa si el producto resuelve algo que alguien necesita hacer.
Una credencial no es útil porque exista, sino porque encaja en una decisión de confianza. Porque evita pedir un documento completo cuando basta con verificar un atributo. Porque permite a una organización actuar con una identidad corporativa verificable. Porque facilita que un ciudadano demuestre una condición sin repetir trámites. Porque permite que sistemas distintos se entiendan sin depender de validaciones manuales o integraciones ad hoc.
El futuro de SSI no se juega solo en la emisión, sino en la experiencia de usar y verificar. En cómo se explican los datos. En cómo se diseña el consentimiento. En cómo se resuelven las excepciones. En cómo se integran las wallets en procesos existentes. En cómo se conectan personas, organizaciones y sistemas dentro de marcos de confianza que puedan sostenerse en producción.
La tecnología ya está empujando. Ahora el reto es hacerla útil.
Podemos conversar sobre SSI, credenciales verificables, EUDI Wallet, interoperabilidad o soluciones de confianza digital que necesiten pasar de la complejidad técnica a experiencias claras, útiles y adoptables.