Presentar una credencial desde un monedero no consiste en “enviar un QR con un JWT”. Es un protocolo entre un emisor, el monedero de una persona y un servicio verificador, con reglas de confianza, consentimiento, minimización, estado e interoperabilidad que el backend debe comprobar deliberadamente.
El marco europeo de identidad digital (EUDI) avanza desde especificaciones y pilotos hacia implementaciones nacionales y pruebas del ecosistema. Los Estados miembros deben ofrecer monederos antes de que termine 2026. Durante 2026, las pruebas de la Comisión reúnen equipos de monederos, emisores, servicios verificadores y laboratorios para comprobar interoperabilidad real, incluidos OpenID for Verifiable Credential Issuance (OpenID4VCI), OpenID for Verifiable Presentations (OpenID4VP) y presentaciones de proximidad basadas en ISO/IEC 18013-5.
Para los equipos de aplicaciones, el cambio es arquitectónico: los datos de identidad se mantienen y presentan desde un monedero controlado por la persona; el servicio que los solicita debe autenticarse, pedir solo atributos registrados y justificados, validar la presentación y tomar una decisión ligada a una finalidad. Comprobar una firma no demuestra por sí solo que se cumplan las demás condiciones de confianza.
El emisor, el proveedor del monedero y la entidad verificadora son funciones de seguridad distintas. Una afirmación del emisor no se vuelve fiable solo por guardarse en el monedero. El verificador necesita un marco de confianza para emisores y tipos de credencial, y debe validar su vinculación criptográfica con el titular o la unidad del monedero según el formato y perfil empleados.
En la emisión, el monedero recibe una oferta o autorización, se autentica cuando corresponde, obtiene una credencial del emisor y la guarda bajo las protecciones del monedero. En la presentación, el servicio verificador crea una solicitud con nonce, audiencia y atributos; la persona revisa finalidad y datos; el monedero devuelve una prueba; y el backend la valida frente a claves confiables, metadatos del emisor, estado y contexto de la transacción.
OpenID4VCI y OpenID4VP son familias de protocolos con perfiles y detalles de implementación. Sigue la Architecture and Reference Framework (ARF) de EUDI, los actos de ejecución aplicables y el perfil de interoperabilidad concreto. Un perfil de piloto, un borrador técnico y una configuración de producción exigida legalmente no son equivalentes.
Una buena pantalla de consentimiento no corrige una solicitud excesiva. Si el servicio solo necesita saber si una persona supera cierta edad, solicita una prueba de ese umbral o el atributo más limitado disponible, no la fecha de nacimiento ni la identidad completa. Las reglas del ecosistema prevén avisos claros cuando el verificador pide atributos que exceden su certificado de acceso registrado; el silencio o una casilla premarcada no sustituyen la aprobación explícita.
El backend debe fijar la finalidad, el conjunto de atributos, la retención, la base jurídica y los usos posteriores antes de construir la solicitud. Cuando sea posible, guarda el resultado de la decisión de negocio en vez de copiar toda la credencial al perfil. Reduce los logs: quizá basten el ID de transacción, el registro del verificador, el resultado y el tipo de credencial; evita registrar por defecto la presentación original, la prueba o los atributos personales.
| Caso de uso | Recopilación excesiva | Mejor solicitud / resultado backend |
|---|---|---|
| Servicio con control de edad | Fecha de nacimiento completa, dirección y número de documento. | Solicita prueba del umbral de edad y conserva solo elegibilidad y referencia de auditoría. |
| Cualificación profesional | Copiar la credencial completa y atributos ajenos a un CRM. | Valida emisor, cualificación y vigencia; conserva la mínima evidencia necesaria. |
| Alta de cuenta | Reutilizar identidad para analítica o marketing sin revisar otra finalidad. | Separa verificación de identidad del perfil opcional y preferencias comerciales. |
| Pago o viaje | Guardar todos los atributos revelados indefinidamente por comodidad de soporte. | Define retención por campo y conserva el recibo sin datos sobrantes. |
Las listas de confianza y los datos de registro son dependencias operativas: usa caché con caducidad limitada, supervisa fallos de actualización y define qué ocurre si la fuente no está disponible. Un comportamiento fail-open puede admitir afirmaciones no fiables; fail-closed puede bloquear usuarios. La respuesta depende del riesgo de la transacción y debe ser deliberada, documentada y observable.
La divulgación selectiva no equivale a imposibilidad de correlación. Reutilizar identificadores estables, cruzar horarios, recopilar metadatos del dispositivo o consultar al emisor/servicio de estado en cada presentación puede vincular transacciones. Revisa conjuntamente qué pueden observar el monedero, verificador, emisor, operador de listas, servicio de estado y analítica. Prefiere identificadores específicos por relación cuando estén soportados, referencias transaccionales breves, telemetría mínima y retención limitada.
El estado de credenciales también exige equilibrio: hay que validar vigencia sin convertir la consulta en una baliza de seguimiento. Sigue el perfil aplicable, entiende sus propiedades de privacidad y evita callbacks adicionales innecesarios. Incluye capturas, exportaciones de soporte, informes de errores y sistemas antifraude en el mismo mapa de datos personales.
Pondría un gateway verificador delante de los servicios de negocio. Autenticaría la configuración de la entidad, crearía solicitudes permitidas desde políticas versionadas, gestionaría callbacks, validaría pruebas, confianza del emisor, estado y replay, y devolvería un comprobante compacto y firmado de la decisión. Podría incluir ID de transacción, versión de política, tipo de credencial, referencia del emisor, resultado y fecha, pero no toda la credencial salvo necesidad legítima concreta.
Las pruebas de contrato cubrirían pruebas malformadas, credenciales caducadas o revocadas, audiencia equivocada, nonce repetido, emisor no fiable, solicitud excesiva, datos de confianza obsoletos y caída del servicio de estado. Usa credenciales sintéticas en pruebas. Gestiona las actualizaciones de protocolos y bibliotecas como cambios explícitos y prueba interoperabilidad con implementaciones de referencia y entornos de aceptación actuales.
| Fallo | Señal | Control |
|---|---|---|
| Firma válida, emisor no fiable | Se acepta una credencial correcta criptográficamente pero de origen no autorizado. | Valida cadena de confianza, autorización, tipo de credencial y política. |
| Replay de presentación | Se acepta una respuesta capturada para otra transacción. | Vincula nonce y audiencia, aplica caducidad y protección contra repetición. |
| El verificador pide atributos extra | La solicitud excede el registro o la finalidad declarada. | Compara con el registro y requiere aviso claro y acción explícita cuando corresponda. |
| Datos de confianza/estado obsoletos | Claves o estado de revocación en caché superan su vigencia permitida. | Limita caché, alerta ante fallos y define respuesta ante caídas según el riesgo. |
| La credencial aparece en logs | Atributos personales aparecen en trazas, analítica o incidencias. | Redacta por defecto, usa datos sintéticos y busca campos prohibidos en telemetría. |
Integrar monederos EUDI significa operar un protocolo distribuido de confianza, con consentimiento comprensible y responsabilidades en el backend. Separa emisor, monedero y verificador; solicita los atributos mínimos; valida prueba, emisor, estado y contexto; y evita replicar credenciales completas en logs o perfiles por defecto. Las pruebas de interoperabilidad no son el acabado final: muestran dónde fallan las hipótesis de confianza.
Nota editorial: Las especificaciones y el despliegue del ecosistema evolucionan. Este artículo refleja materiales oficiales consultados el 28 de septiembre de 2026; no es asesoramiento jurídico, certificación ni prueba de identidad. Sigue el marco EUDI, los actos de ejecución y las directrices nacionales vigentes para cada integración.