Aceptar una presentación de EUDI Wallet es una decisión de confianza, y el código de su integración es donde se toma esa decisión. Este artículo está dirigido a las relying parties: los ayuntamientos y proveedores de servicios que aceptarán presentaciones de la wallet, no los equipos que desarrollan wallets. Recoge las preguntas que querríamos ver respondidas antes de activar la wallet para usuarios reales, a modo de lista de revisión y no de diseño definitivo.
Sepa contra qué especificación está construyendo
La base técnica es la Architecture and Reference Framework (ARF). Se publica en un repositorio público de GitHub y se desarrolla en el marco de la Common Union Toolbox. El repositorio indica que la última versión de referencia es la release etiquetada más reciente. Una rama o el resumen de un blog no son fuentes de referencia.
La base jurídica es el Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183, junto con sus Reglamentos de Ejecución de la Comisión. La ARF remite a la lista actualizada de estos en sus secciones de Introducción y Referencias.
Por tanto, las primeras preguntas son administrativas, pero importan:
- ¿Contra qué release de la ARF ha construido su proveedor o integrador?
- ¿Quién de su organización hace seguimiento de las nuevas releases etiquetadas y de los reglamentos de ejecución, y cómo llegan los cambios a su backlog?
- ¿El contrato con el proveedor de identidad menciona una versión concreta, o solo "conforme con eIDAS 2.0"?
Preguntas sobre la aserción
La wallet entrega a su servicio una presentación. Antes de que pueda convertirse en una sesión, debe saber qué ha verificado.
- ¿Quién la ha emitido? Su servicio debería aceptar presentaciones únicamente de emisores en los que haya decidido confiar, y para los tipos de atributo que haya decidido aceptar. "Cualquier firma válida" no es una política. Deje por escrito la lista de aceptación, nombre a un responsable y defina cómo se añaden y se retiran entradas.
- ¿Está vinculada a esta transacción? Una presentación que pueda reutilizarse (replay) contra su endpoint de login es una credencial robada a la espera de ser usada. Confirme con su proveedor cómo se vincula una presentación a su sesión y compruebe mediante pruebas que se rechaza una presentación antigua.
- ¿Qué ocurre cuando la verificación falla o no está disponible? Decida si el sistema debe fallar de forma cerrada (fail closed). Compruebe que la gestión de errores y las condiciones de carga no derivan a los usuarios hacia una vía alternativa más débil.
- ¿Qué registra en logs? Necesita lo suficiente para investigar un incidente sin almacenar los datos personales que la wallet se diseñó para mantener al mínimo.
Una aclaración sobre el primer punto: la política de aceptación de emisores y atributos es el control que recomendamos nosotros. No es un requisito citado de la ARF.
Preguntas sobre los atributos
La Comisión describe la wallet como una herramienta que permite al usuario revelar solo los datos necesarios, como la edad o la nacionalidad, y no el resto de sus datos personales. Esa es la expectativa que su integración, como relying party, debe cumplir.
Si su servicio necesita saber que alguien supera una determinada edad, solicite eso y no la fecha de nacimiento. Si necesita a un residente de su municipio, solicite el atributo que lo acredita y no la dirección completa. Cada atributo adicional que solicite aumenta los datos que debe proteger y justificar en su propia evaluación de impacto sobre la privacidad.
Después, pregúntese qué demuestra realmente el atributo. Un atributo de un emisor público y otro de un emisor privado pueden convivir en la misma wallet y parecer iguales en su código. Asocie cada uno con la decisión a la que da soporte. El número de un carné de biblioteca no debería dar acceso a la presentación de impuestos.
Una fila de la política de aceptación podría tener este aspecto. Los valores ilustran el formato y no constituyen una recomendación:
| Emisor | Atributo | Decisión de la relying party | Responsable | Intervalo de revisión |
|---|---|---|---|---|
| Emisor de identidad nacional (ejemplo) | Mayor de 18 años | Permitir el acceso al servicio con restricción de edad; no almacenar la fecha de nacimiento | Responsable del servicio | Cada seis meses |
Si no puede completar las cinco columnas de una entrada, esa entrada no está lista para incluirse en la lista.
En cuanto al uso organizativo, los pilotos están probando las identidades digitales organizativas como caso de uso: acreditar que una persona es representante legítimo de una organización. Si presta servicio a empresas, decida desde ahora cómo tratará a una persona que actúa en nombre de una empresa y cómo se enterará de que su facultad de representación ha terminado.
Preguntas sobre los flujos de firma
La firma de contratos es uno de los escenarios piloto, así que trátela como un caso de aseguramiento distinto del login.
- ¿De qué servicios depende su flujo de firma o de sellado, y quién los opera?
- ¿Qué conserva como evidencia de una firma y durante cuánto tiempo?
- Si una firma se impugna dentro de dos años, ¿puede demostrar qué se presentó y qué se verificó en ese momento?
No dé por sentado que un login correcto implica una cadena de firma válida. Son comprobaciones distintas, con modos de fallo distintos. Sus equipos jurídico y de seguridad deberían acordar qué se considera una evidencia aceptable antes de que se firme el primer contrato.
Pruebe la integración y vuelva a probarla
La wallet prototipo de la Comisión incluye bibliotecas de código y una aplicación de ejemplo, y la implementación de referencia es de código abierto. El repositorio de la ARF enlaza a un sitio web de conformidad. Utilice estos recursos para las pruebas, no como una dependencia de producción que nunca haya revisado.
Los pilotos a gran escala reúnen a más de 350 entidades de 26 Estados miembros, Noruega, Islandia y Ucrania, y abarcan ámbitos como los servicios públicos, la banca y los pagos. Aun así, sus propios endpoints, vías alternativas y gestión de sesiones requieren sus propias pruebas.
Trate la integración como código de autenticación nuevo. Eso implica un modelo de amenazas, pruebas de casos de abuso frente a replay, presentaciones malformadas y emisores inesperados, y una prueba de penetración del flujo terminado antes del lanzamiento. Con independencia de lo que haya probado el proveedor de la wallet, su servicio como relying party necesita su propia revisión.
Por dónde empezar
- Fije su objetivo: registre la release de la ARF y los reglamentos de ejecución contra los que se construye su integración, y asigne a alguien para vigilar los cambios.
- Redacte una política de aceptación: enumere los emisores y tipos de atributo en los que confiará, la decisión a la que da soporte cada uno, el responsable y el intervalo de revisión.
- Reduzca sus solicitudes de atributos al mínimo que necesita cada servicio y deje constancia del resultado en su propia evaluación de impacto sobre la privacidad.
- Elabore un plan de pruebas sobre la implementación de referencia y los recursos de conformidad, que incluya casos de replay, emisor incorrecto, modos de fallo y vías alternativas.
- Separe el login de la firma: decida qué evidencias conserva en cada caso y quién da el visto bueno.
- Obtenga una revisión independiente antes de la puesta en producción. Si desea ayuda para definir su alcance, hable con nuestro equipo de consultoría.
