El ARF — la arquitectura de la EUDI Wallet por dentro
Un reglamento puede ordenar que exista una billetera de identidad. Lo que no puede es lograr que una credencial emitida en Atenas se verifique en Dublín sin que nadie levante un teléfono. Para eso existe el ARF — Architecture and Reference Framework: el plano técnico común del ecosistema EUDI Wallet, mantenido por la Comisión Europea junto a los Estados miembro, publicado y versionado abiertamente en GitHub (versión vigente a mediados de 2026: 2.8). No es ley — los vinculantes son el Reglamento 2024/1183 y sus actos de ejecución — pero es el documento que traduce las obligaciones legales en arquitectura, formatos y protocolos concretos.
Para un equipo técnico provincial argentino es el documento más aprovechable del proceso europeo: define el estado del arte global de las credenciales verificables, con los mismos estándares abiertos que adopta el ecosistema argentino. Y se lee gratis.
La taxonomía: PID, QEAA, EAA
Dentro de la wallet viven tres especies de documentos digitales:
- PID (Person Identification Data) — el núcleo identitario: los atributos que dicen quién es la persona, definidos por el Reglamento de Ejecución 2024/2977 (lista de atributos obligatorios y opcionales). Lo emite cada Estado miembro o su proveedor designado, y convierte a la wallet en un medio de identificación con nivel de garantía alto. Equivalente funcional argentino: los datos del DNI como credencial-raíz.
- QEAA (Qualified Electronic Attestations of Attributes) — atestaciones de atributos (título, licencia profesional, poder de representación) emitidas por un prestador cualificado de servicios de confianza supervisado por el Estado. Máxima confianza institucional.
- EAA — la misma idea sin el régimen cualificado: cualquier organización puede emitirlas, válidas y verificables criptográficamente, con menor blindaje institucional. Las emitidas por organismos públicos responsables de registros auténticos tienen estatus propio reforzado.
La estructura de dos niveles (cualificado con garantías fuertes / no cualificado válido) es la misma lógica que la Ley 25.506 argentina aplica a firma digital vs. electrónica — Europa y Argentina vuelven a converger en arquitectura jurídica.
Los dos formatos obligatorios
El ecosistema EUDI no eligió un formato ganador: estandarizó dos, cada uno dueño de un escenario, y obligó a que el PID se emita en ambos.
| SD-JWT VC | mDoc / ISO/IEC 18013-5 | |
|---|---|---|
| Qué es | JWT con divulgación selectiva (el titular presenta solo los atributos necesarios) | Estándar ISO nacido para la licencia de conducir móvil (mDL) |
| Escenario dominante | Remoto / web / nativo digital | Presencial / NFC / QR / offline |
| Linaje | IETF, evolución del JWS/JWT que ya domina la web | ISO, con despliegue real en licencias digitales en producción; ISO/IEC 18013-7 extiende a presentación remota |
Los protocolos de transporte completan el cuadro: OpenID4VCI para emisión y OpenID4VP para presentación. El dato operativo para una provincia: si emitís credenciales SD-JWT VC sobre OpenID4VCI/VP, hablás el mismo idioma técnico que la infraestructura de identidad de la UE.
La capa de confianza
La criptografía prueba que una credencial fue firmada por la clave X y no fue alterada. No puede probar que la clave X pertenece al Ministerio de Salud y no a un impostor. Eso lo resuelve la capa de confianza, con cuatro piezas:
- QTSPs — prestadores cualificados de servicios de confianza: auditados, supervisados, responsables. La figura del "certificador licenciado" argentino con dos décadas de rodaje europeo.
- Trust lists — cada Estado publica su lista firmada de prestadores y claves; la Comisión publica la lista de listas. Un verificador en cualquier país comprueba automáticamente si un emisor es confiable — sin acuerdos bilaterales ni bases compartidas. Es el equivalente europeo del registro de emisores del Protocolo Federado.
- Verificadores registrados — las relying parties deben registrarse en su Estado para poder pedir datos: hasta el que verifica está identificado, para que el ciudadano sepa quién le pide qué.
- Certificación obligatoria de wallets — ninguna EUDI Wallet llega al público sin certificarse ante organismos de evaluación de la conformidad acreditados, demostrando los requisitos funcionales, de seguridad y de privacidad de los actos de ejecución y el nivel de garantía alto (LoA High): protección de claves en hardware seguro y resistencia a atacantes de capacidad alta. LoA High no es un detalle técnico — es la vara que define qué trámites puede habilitar la wallet.
El principio transversal: nadie se autodeclara confiable. Cada eslabón tiene un tercero que lo controla y un mecanismo público para comprobarlo.
El error conceptual a evitar
No existe "la app EUDI". Existe una arquitectura común y muchas wallets que la implementan — al menos una por Estado, públicas o privadas certificadas. Lo común es el estándar, no el software. El error simétrico argentino sería creer que la identidad federal exige una única aplicación para todas las provincias: exige un único protocolo.
El mapa mental
- Emite: el Estado (PID), los QTSP (QEAA), el resto del ecosistema (EAA) — todos firman.
- Porta: la persona, en su wallet certificada, con divulgación selectiva.
- Verifica: relying parties registradas, contra trust lists, sin bases centrales.
- Certifica y controla: organismos de conformidad (wallets, LoA High), supervisores nacionales (QTSPs), trust lists (quién es quién).
Cuatro roles, todo verificable públicamente. Veintisiete países, muchas wallets, un solo protocolo — el modelo a escala europea de lo que el Protocolo Federado propone a escala provincial.
Para seguir
- eIDAS Trust List — modelo regulatorio UE — la pieza de confianza en profundidad
- JWS y JWT — formato estándar de firmas — el linaje técnico de SD-JWT VC
- De eIDAS 1.0 a 2.0 — qué cambió y por qué — el contexto regulatorio de esta arquitectura