{"id":1120,"date":"2026-03-31T09:23:18","date_gmt":"2026-03-31T09:23:18","guid":{"rendered":"https:\/\/macarenatorralba.es\/?p=1120"},"modified":"2026-06-09T10:16:10","modified_gmt":"2026-06-09T10:16:10","slug":"credenciales-verificables-reto-caso-de-uso","status":"publish","type":"post","link":"https:\/\/macarenatorralba.es\/es\/credenciales-verificables-reto-caso-de-uso\/","title":{"rendered":"Credenciales verificables: el reto no es emitirlas, es hacerlas \u00fatiles"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t

Credenciales verificables: el reto no es emitirlas, es hacerlas \u00fatiles<\/h1>\n\t\t\t\t\t

Una credencial verificable solo aporta valor cuando resuelve una decisi\u00f3n de confianza en un contexto real. No basta con emitirla correctamente: tiene que ser comprensible para quien la recibe, \u00fatil para quien la presenta y verificable para quien necesita confiar en ese dato.<\/p>\n\t\t\t\t\t

SSI \u00b7 Credenciales verificables \u00b7 EUDIW \u00b7 eIDAS2 \u00b7 Business Wallet \u00b7 Interoperabilidad<\/p>\n\t\t\t\t

\n\t\t\t\t\t
<\/div>\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t

La identidad digital necesita producto, no solo est\u00e1ndares<\/h2>\n\t\t\t\t\t

El reto de SSI no es solo emitir credenciales, sino dise\u00f1ar experiencias donde personas, organizaciones y sistemas puedan confiar, compartir y verificar datos de forma \u00fatil.<\/p>\n\t\t\t\t\t

En los \u00faltimos a\u00f1os, 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\u00f3n del marco europeo, con eIDAS2, EUDI Wallet y el ARF, ha acelerado todav\u00eda m\u00e1s esa conversaci\u00f3n. Pero para m\u00ed, el reto sigue estando en el mismo sitio: convertir un modelo t\u00e9cnico potente en experiencias que puedan entenderse, adoptarse y usarse en contextos reales.

Emitir una credencial verificable puede ser t\u00e9cnicamente complejo, pero no es suficiente. La pregunta importante no es solo si una credencial se puede emitir, almacenar o verificar. La pregunta es qu\u00e9 problema resuelve, qu\u00e9 dato necesita ser confiable, qui\u00e9n debe presentarlo, qui\u00e9n debe verificarlo, en qu\u00e9 momento del proceso y con qu\u00e9 consecuencias.

Ah\u00ed es donde el enfoque de producto se vuelve clave. Porque SSI no es \u00fanicamente 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\u00edas.

El valor de una credencial verificable no est\u00e1 en que exista, sino en que encaje en una decisi\u00f3n de confianza.<\/p>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t\t

Cuando la credencial existe, pero nadie sabe usarla<\/h2>\n\t\t
\n\t\t
\n\t\t\t\t\t

Uno de los errores m\u00e1s habituales al trabajar con credenciales verificables es pensar que el problema termina cuando la credencial ha sido emitida correctamente. Desde una perspectiva t\u00e9cnica, 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\u00ed 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\u00f3n. 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\u00f3gica cambia: la persona puede custodiar atributos, presentar pruebas, compartir solo determinada informaci\u00f3n y operar con mayor control sobre sus datos. Esto tiene un valor enorme, pero tambi\u00e9n introduce una complejidad nueva.

Para muchas personas, una wallet puede convertirse f\u00e1cilmente en un caj\u00f3n de documentos digitales. Algo donde se guardan credenciales, certificados o atributos, pero sin una comprensi\u00f3n clara de qu\u00e9 significan, cu\u00e1ndo deben usarse, qu\u00e9 datos contienen o qu\u00e9 implica presentarlos. Si la experiencia no acompa\u00f1a, el ciudadano puede terminar aceptando, compartiendo o rechazando informaci\u00f3n sin entender del todo la acci\u00f3n que est\u00e1 realizando.

Tambi\u00e9n puede ocurrir lo contrario: que el caso de uso est\u00e9 perfectamente construido en una demo, pero no encaje en un proceso real. Una prueba de emisi\u00f3n y verificaci\u00f3n puede funcionar en laboratorio, pero fallar cuando aparecen roles, permisos, excepciones, revocaciones, expiraciones, representaci\u00f3n organizacional, soporte, onboarding, sistemas heredados o necesidad de interoperar con distintos marcos de confianza.

Otro error frecuente es utilizar blockchain como sin\u00f3nimo 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\u00ed sola la utilidad de una credencial verificable. El valor est\u00e1 en el flujo de emisi\u00f3n, custodia, presentaci\u00f3n y verificaci\u00f3n; en el marco de confianza que lo sostiene; y en la capacidad de integrarlo en procesos donde exista una necesidad real de verificar informaci\u00f3n.

El reto, por tanto, no es solo t\u00e9cnico. Es de adopci\u00f3n, de experiencia, de confianza y de producto.<\/p>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t\"fotograf\u00eda\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t

Hacer \u00fatiles las credenciales exige dise\u00f1ar el contexto<\/h2>\n\t\t\t\t\t

Antes de dise\u00f1ar una soluci\u00f3n basada en SSI, hay que entender qu\u00e9 relaci\u00f3n 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\u00f3n.<\/p>\n\t\t

\n\t\t
\n\t\t\t\t\t
<\/div>\t\t
\n\t\t\t\t\t

El valor est\u00e1 en la verificaci\u00f3n<\/h2>\n\t\t\t\t\t

Una credencial verificable tiene sentido cuando permite confiar en un dato sin depender de procesos manuales, documentos est\u00e1ticos o comprobaciones poco trazables. Puede servir para demostrar una condici\u00f3n, una autorizaci\u00f3n, una cualificaci\u00f3n, una pertenencia, una elegibilidad o una representaci\u00f3n. Pero su utilidad aparece cuando esa prueba reduce fricci\u00f3n, aumenta confianza o permite tomar una decisi\u00f3n con mayor seguridad.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
<\/div>\t\t
\n\t\t\t\t\t

La wallet no puede ser un caj\u00f3n<\/h2>\n\t\t\t\t\t

Una wallet debe ayudar al ciudadano a entender qu\u00e9 credenciales tiene, qui\u00e9n las ha emitido, qu\u00e9 datos contienen y qu\u00e9 ocurre cuando decide presentarlas. La experiencia debe hacer comprensible el consentimiento: qu\u00e9 se comparte, con qui\u00e9n, para qu\u00e9 y durante cu\u00e1nto tiempo. Automatizar parte del proceso puede ser \u00fatil, pero siempre debe mantenerse una acci\u00f3n expl\u00edcita y comprensible cuando se comparten datos relevantes.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
<\/div>\t\t
\n\t\t\t\t\t

El paradigma necesita traducci\u00f3n<\/h2>\n\t\t\t\t\t

SSI introduce conceptos que no siempre son evidentes fuera del nicho t\u00e9cnico: issuer, holder, verifier, DID, proof, revocation, trust framework, selective disclosure o verifiable presentation. El reto de UX y producto est\u00e1 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.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
<\/div>\t\t
\n\t\t\t\t\t

Personas y organizaciones no funcionan igual<\/h2>\n\t\t\t\t\t

No es lo mismo dise\u00f1ar una Holder Wallet para ciudadanos que una Business Wallet para organizaciones. En el \u00e1mbito enterprise aparecen necesidades adicionales: identidad organizacional, atributos corporativos, representaci\u00f3n, permisos, delegaci\u00f3n, trazabilidad interna y actuaci\u00f3n en nombre de una entidad. La experiencia debe contemplar no solo qui\u00e9n eres, sino en calidad de qu\u00e9 act\u00faas y con qu\u00e9 autoridad.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t\t

Del est\u00e1ndar al caso de uso<\/h2>\n\t\t
\n\t\t
\n\t\t\t\t\t

Trabajo para traducir flujos t\u00e9cnicos complejos en experiencias que puedan entenderse, validarse y utilizarse en contextos reales.<\/h2>\n\t\t\t\t<\/div>\n\t\t
\n\t\t
\n\t\t\t\t\t

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\u00e9 est\u00e1ndar vamos a utilizar, sino qu\u00e9 dato necesita ser confiable y qu\u00e9 decisi\u00f3n depende de verificarlo.

A partir de ah\u00ed, es necesario mapear los actores del flujo. Qui\u00e9n emite la credencial, qui\u00e9n la recibe, qui\u00e9n la custodia, qui\u00e9n la presenta y qui\u00e9n la verifica. Tambi\u00e9n hay que entender si hablamos de una persona f\u00edsica, una organizaci\u00f3n, un representante o un sistema que necesita operar dentro de un marco de confianza. Esta diferencia cambia completamente la experiencia y la l\u00f3gica funcional.

Despu\u00e9s viene la conversaci\u00f3n t\u00e9cnica. No se puede dise\u00f1ar una buena experiencia SSI sin hablar con el equipo t\u00e9cnico sobre viabilidad, est\u00e1ndares, integraciones, formatos, protocolos, revocaci\u00f3n, expiraci\u00f3n, confianza, seguridad y restricciones del ecosistema. eIDAS2, EUDI Wallet y el ARF son referencias importantes porque ayudan a ordenar un marco com\u00fan, pero no todas las wallets ni todos los casos de uso son estrictamente EUDI Wallet. Aun as\u00ed, estar alineados con ese marco importa: por interoperabilidad, por expectativas de mercado, por evoluci\u00f3n regulatoria y por la necesidad de no construir soluciones aisladas.

<\/p>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t

Ese trabajo t\u00e9cnico despu\u00e9s tiene que traducirse a UX. Un ciudadano no deber\u00eda necesitar entender el ARF para saber qu\u00e9 est\u00e1 compartiendo. Una organizaci\u00f3n no deber\u00eda tener que interpretar conceptos criptogr\u00e1ficos para operar con una Business Wallet. Un verificador no deber\u00eda enfrentarse a un flujo opaco para saber si una credencial es v\u00e1lida, est\u00e1 vigente y procede de una entidad confiable.

Para m\u00ed, el reto est\u00e1 en automatizar todo lo que pueda reducir fricci\u00f3n sin eliminar control. Si el sistema puede reconocer una credencial, interpretar su estado, validar su emisor o preparar una presentaci\u00f3n, perfecto. Pero cuando hay intercambio de datos personales, autorizaci\u00f3n o presentaci\u00f3n de atributos relevantes, el consentimiento debe ser expl\u00edcito, entendible y proporcionado.

Tambi\u00e9n hay que dise\u00f1ar el contexto de error. Qu\u00e9 ocurre si una credencial est\u00e1 revocada, si ha caducado, si el verifier no la acepta, si falta un atributo, si la wallet no es compatible o si la organizaci\u00f3n no tiene autorizaci\u00f3n para actuar. Muchos prototipos funcionan bien en el happy path, pero los productos reales se sostienen en c\u00f3mo resuelven las excepciones. Por eso, aterrizar SSI en producto exige una mirada h\u00edbrida: entender el est\u00e1ndar, hablar con tecnolog\u00eda, comprender el proceso de negocio y dise\u00f1ar una experiencia que no exponga al ciudadano o a la organizaci\u00f3n a una complejidad innecesaria.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t\t

La utilidad es la verdadera adopci\u00f3n<\/h2>\n\t\t
\n\t\t\t\t\t

La identidad digital no se adopta por est\u00e1ndar, se adopta por utilidad.<\/h2>\n\t\t\t\t\t

Las credenciales verificables tienen un potencial enorme para transformar c\u00f3mo compartimos y verificamos informaci\u00f3n. Pueden reducir fricci\u00f3n, 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 \u00fatil porque exista, sino porque encaja en una decisi\u00f3n de confianza. Porque evita pedir un documento completo cuando basta con verificar un atributo. Porque permite a una organizaci\u00f3n actuar con una identidad corporativa verificable. Porque facilita que un ciudadano demuestre una condici\u00f3n sin repetir tr\u00e1mites. 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\u00f3n, sino en la experiencia de usar y verificar. En c\u00f3mo se explican los datos. En c\u00f3mo se dise\u00f1a el consentimiento. En c\u00f3mo se resuelven las excepciones. En c\u00f3mo se integran las wallets en procesos existentes. En c\u00f3mo se conectan personas, organizaciones y sistemas dentro de marcos de confianza que puedan sostenerse en producci\u00f3n.

La tecnolog\u00eda ya est\u00e1 empujando. Ahora el reto es hacerla \u00fatil.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\n
\n \n <\/span>\n Entrada anterior<\/span>\n <\/a>\n\n \n Entrada siguiente<\/span>\n <\/span>\n <\/a>\n<\/section>\n\n