Volver al blogmdoc de la UE frente a SD-JWT suizo: dos ecosistemas de verificación de edad, un mismo objetivo, cimientos incompatibles

Cuando las carteras cruzan fronteras: lo que Suiza revela sobre la interoperabilidad global


"Interoperabilidad" suele querer decir "dentro de la UE"

Cuando en el espacio europeo de identidad digital alguien dice "interoperabilidad", casi siempre se refiere a una sola cosa: hacer que las EUDI Wallet nacionales se entiendan entre sí. Una cartera francesa demostrando la edad ante un servicio alemán. Una credencial danesa aceptada por una plataforma española. Es un problema real y difícil, y la UE está haciendo un trabajo serio para resolverlo — una regulación común (eIDAS2), un marco de referencia común (el ARF), un Blueprint de verificación de edad compartido y un mecanismo de coordinación pensado, en palabras de la propia Comisión, para converger en una solución interoperable en lugar de veintisiete divergentes.

Pero el mundo es más grande que la UE. Y en cuanto sales del paraguas de eIDAS2, la "interoperabilidad" deja de ser un problema de coordinación y pasa a ser un problema de arquitectura — porque los ecosistemas que te encuentras ahí fuera se construyeron sobre cimientos distintos.

No hace falta ir lejos para verlo. Suiza — vecina, no estado miembro — ya opera uno de los ecosistemas de cartera más maduros de Europa. Su e-ID tiene base legal, una infraestructura en beta pública y credenciales reales en circulación. Y también hace verificación de edad. El mismo objetivo que la UE. Casi ninguna de las mismas decisiones técnicas.

Suiza es la ventana más clara que tenemos hacia una pregunta que el trabajo de interoperabilidad de la UE, mirando hacia dentro, no responde: cuando el mundo se llene de carteras nacionales soberanas, ¿cómo interoperan entre sí?

La misma intención, todo lo demás distinto

Empecemos por lo que comparten, porque es mucho. El ecosistema suizo — construido en torno a la infraestructura gubernamental swiyu — quiere exactamente lo que quiere la UE para la verificación de edad: dejar que un usuario demuestre que es mayor de 18 sin entregar su nombre, su fecha de nacimiento ni su documento. Privacidad por diseño. Minimización de datos. Claves en el dispositivo del usuario. La prueba revela un único hecho y nada más.

En la intención, los dos sistemas son gemelos. Un residente suizo demostrando "mayor de 18" ante una web y un residente italiano haciendo lo mismo viven, conceptualmente, la misma experiencia respetuosa con la privacidad.

Por debajo, hablan idiomas distintos — y no dialectos del mismo. Idiomas distintos.

Dónde divergen de verdad los dos ecosistemas

Aquí es donde una decisión de diseño tomada en Bruselas y una decisión de diseño tomada en Berna dejan de ser compatibles. Tres ejes son los que más pesan.

Formato de credencial: mdoc frente a SD-JWT VC

El Blueprint de verificación de edad de la UE, y las carteras nacionales que lo integran, se apoyan en mdoc — el formato de documento móvil ISO/IEC 18013-5 (y 18013-7). Es el mismo linaje que el permiso de conducir móvil. Es binario, codificado en CBOR, y trae su propia maquinaria de divulgación selectiva.

Suiza fue por el otro camino. swiyu se apoya en SD-JWT VC — JSON Web Tokens con divulgación selectiva. La credencial es una estructura JSON firmada con claims individualmente divulgables mediante salting. El perfil técnico suizo es explícito: las credenciales ISO mdoc no están soportadas en su flujo de verificación.

Aquí conviene una precisión, porque es fácil equivocarse. SD-JWT VC no es un formato exótico ajeno a Europa: es uno de los dos formatos de credencial que soporta el EUDI Architecture and Reference Framework, junto a mdoc. La división no es "formato de la UE frente a formato foráneo". Lo que ocurrió es más concreto — el Blueprint de verificación de edad de la UE estandarizó específicamente en mdoc, mientras que Suiza construyó toda su pila sobre SD-JWT VC. Ambos formatos son ciudadanos de primera del marco europeo de carteras; los dos ecosistemas simplemente eligieron opciones distintas de un menú que se solapa, y para la verificación de edad en concreto acabaron en opciones diferentes.

No son dos codificaciones de lo mismo. Son dos paradigmas de credencial distintos, con librerías distintas, convenciones de firma distintas y mecánicas de divulgación selectiva distintas. Un verificador construido para validar uno no valida el otro con activar un flag de configuración. Tiene que implementar el segundo paradigma desde cero.

Modelo de confianza: trust list X.509 frente a DID + registro de confianza

Aunque los formatos coincidieran, la brecha más dura es la confianza. Cuando un verificador recibe una prueba, tiene que responder a una pregunta: ¿puedo confiar en el emisor que la firmó? Los dos ecosistemas la responden de formas incompatibles.

El modelo de verificación de edad de la UE ancla la confianza en una trust list X.509 firmada — la EU Age Verification Trusted List, una estructura al estilo ETSI que enumera los emisores acreditados y permite a un verificador recorrer una cadena de certificados hasta una raíz conocida. Es PKI clásica: certificados, cadenas, una lista firmada que descargas y validas.

Suiza ancla la confianza en identificadores descentralizados. Los emisores se identifican mediante DIDs (el método did:webvh), que se resuelven y validan contra el propio registro de confianza de swiyu. No hay trust list X.509 que recorrer. El verificador resuelve un DID, lo comprueba contra un registro suizo, y confía sobre esa base.

Esta es la incompatibilidad más profunda de las tres. El formato de credencial es cuestión de parseo; el anclaje de la confianza es gobernanza hecha técnica. Un ecosistema dice "la confianza fluye desde una lista firmada de certificados". El otro dice "la confianza fluye desde un registro de identificadores descentralizados". Un verificador que quiera aceptar ambos tiene que ejecutar dos caminos de establecimiento de confianza completamente separados.

Más abajo en la pila, más acuerdo del que esperarías

Quedaría redondo decir que la divergencia continúa hasta el fondo, pero no es así — y conviene ser preciso sobre dónde vive de verdad la incompatibilidad. En la capa criptográfica los dos ecosistemas coinciden en gran medida: ambos estandarizan firmas ES256 sobre la curva NIST P-256, y ambos recurren a una status list — la Token Status List del IETF — para la revocación cuando la necesitan. (En verificación de edad la credencial suele ser de un solo uso y de vida corta, así que la revocación apenas entra en juego.) Lo único que Suiza añade realmente de su cosecha es OCA (Overlays Capture Architecture), para la presentación visual de las credenciales — una pieza para la que el modelo de verificación de edad de la UE no tiene equivalente directo.

Así que el cuadro no es "todas las capas son incompatibles". La curva y la revocación convergen. La incompatibilidad se concentra justo donde más duele: el formato de credencial y — la más profunda — el modelo de confianza. Esas son las dos capas que un verificador no puede disimular, y son las dos que no encajan.

Siendo justos con ambos: son sistemas bien diseñados, y el suizo sigue en beta pública y explícitamente sujeto a cambios. Esto no va de que un lado lo haya hecho mal. Va de dos equipos capaces tomando decisiones coherentes e internamente consistentes que, sencillamente, no encajan entre sí.

Por qué este es el problema de interoperabilidad que nadie ha resuelto

Aquí está la parte incómoda. La UE ha hecho el trabajo difícil de que la interoperabilidad funcione dentro de su propio marco — y ese trabajo es genuinamente impresionante. Pero resolvió la interoperabilidad imponiendo un marco compartido. Eso solo funciona para los países dentro del mandato.

Suiza es una sola vecina, y las costuras ya son estructurales: formato distinto, modelo de confianza distinto, convenciones criptográficas distintas. Ahora multiplica eso por cada jurisdicción del planeta que está construyendo — o construirá — su propia cartera digital soberana. El Reino Unido. Varias iniciativas de estados de EE. UU. Singapur. Cada país que decide que la identidad digital es infraestructura nacional y la construye según sus propias especificaciones.

Un relying party — un servicio que necesita verificar edad o identidad — no puede permitirse decir "solo acepto carteras de la UE". Sus usuarios vienen de todas partes. Y "aceptar otra cartera" no es un cambio de configuración cuando esa otra cartera vive en un paradigma de credencial distinto con una raíz de confianza distinta. Es una segunda implementación.

La UE resolvió la interoperabilidad interna. La interoperabilidad global — entre ecosistemas construidos sobre cimientos incompatibles — está sin resolver, y no está claramente en la hoja de ruta de nadie como problema con un dueño único. Cae en el hueco entre los organismos de estandarización, los gobiernos nacionales y quien acabe teniendo que aceptar de verdad credenciales de más de un mundo.

La parte que se resuelve y la parte que no

Hay una forma útil de ver esta división, y la propia UE acaba de darnos la evidencia.

A mediados de 2026, la Comisión Europea y la Digital Agency de Japón publicaron los resultados de un piloto de interoperabilidad transfronteriza: un prototipo de EUDI Wallet y una cartera japonesa emitiendo, custodiando, presentando y verificando credenciales académicas la una de la otra, en ambos sentidos. En lo técnico, funcionó. Se alinearon en protocolos comunes — el OpenID4VC High Assurance Interoperability Profile y SD-JWT VC — y las credenciales fluyeron entre dos jurisdicciones cuyos marcos se diseñaron de forma completamente independiente. La conclusión de titular fue optimista: la interoperabilidad no requiere un único marco compartido, solo alineación en protocolos comunes.

Pero si lees más allá del titular encuentras exactamente dónde está el muro. El propio informe señala que los mayores obstáculos que quedan no son técnicos sino legales — en concreto, los marcos de reconocimiento mutuo y de confianza que darían a una credencial transfronteriza validez legal. Para que la confianza funcionara siquiera en el piloto, las dos partes tuvieron que apoyarse en conocimiento fuera de banda y en el esquema nacional japonés de certificación de e-seals — es decir, cerraron el círculo de confianza en parte a mano, con acuerdos fuera del sistema, en lugar de mediante un mecanismo automático e interoperable. El piloto demostró que se puede mover el formato a través de una frontera. No resolvió mover la confianza a través de una frontera.

Esa distinción es todo el juego. Alinear protocolos es la parte tratable — un perfil aquí, un formato de credencial allá, y los bits fluyen. Establecer confianza mutua es la parte difícil, porque no es un problema de ingeniería en absoluto: necesita acuerdos internacionales, reglas de responsabilidad alineadas y reconocimiento legalmente vinculante entre estados. Una nota reciente de política del Banco Mundial sobre marcos de carteras digitales llega al mismo punto, señalando el reconocimiento legal como factor decisivo para la interoperabilidad y la confianza de las carteras. Y el coste de no tenerlo se ve más cerca de casa: el Reino Unido, post-Brexit, queda fuera de la arquitectura de reconocimiento mutuo de la UE, así que los servicios de confianza británicos operan como "tercer país" — técnicamente capaces de alinearse en protocolos, pero sin la validez legal automática que confiere el reconocimiento dentro del marco.

Así que el patrón se repite a cada escala. Suiza muestra la divergencia de forma estructural — cimientos distintos, justo al lado. El piloto UE-Japón muestra que incluso un esfuerzo deliberado y bien dotado para tender un puente entre dos ecosistemas alinea los protocolos y luego se atasca en el marco de confianza. El Reino Unido muestra que hasta un antiguo miembro queda fuera del perímetro de confianza en cuanto sale del marco legal compartido. Los formatos convergen. La confianza no — y la confianza es la parte que de verdad decide si un verificador puede aceptar una credencial.

La pregunta abierta

¿Hacia dónde va esto? Dos futuros, a grandes rasgos.

En uno, los ecosistemas convergen despacio — los organismos de estandarización hacen su trabajo, mdoc y SD-JWT VC tienden puentes, los modelos de confianza encuentran terreno común, y dentro de una década una cartera es una cartera estés donde estés. Es posible. Los estándares a veces ganan.

En el otro, el futuro son carteras soberanas que nunca convergen del todo, porque la identidad digital nacional está demasiado ligada a la gobernanza nacional como para estandarizarla y hacerla desaparecer — y la interoperabilidad ocurre a través de capas de traducción que hablan el idioma de cada ecosistema para que el relying party no tenga que hacerlo. En ese mundo, alguien tiene que construir la cosa que acepta una prueba mdoc de la UE, una prueba SD-JWT suiza y una credencial británica, y devuelve la misma respuesta limpia al servicio que hay detrás.

No sé qué futuro nos toca. Pero sé que hoy, si quieres verificar la edad contra una cartera danesa y una suiza a la vez, no estás configurando un producto — estás hablando dos idiomas. Y el número de idiomas solo va a crecer.

Ese es el verdadero problema de interoperabilidad. No hacer que Europa hable consigo misma. Hacer que Europa hable con todos los demás.


Este artículo se apoya en documentación pública: el Blueprint de verificación de edad de la UE (ageverification.dev) y las especificaciones técnicas del swiyu suizo (swiyu-admin-ch.github.io), que están en beta pública y sujetas a cambios, y el informe publicado por la Comisión Europea sobre el piloto de interoperabilidad UE-Japón. Refleja mi propia lectura como ingeniero que trabaja en el lado del relying party de la verificación de edad EUDI; no representa a ninguna organización.

Las fuentes de este artículo están enlazadas en el propio texto. Para el listado completo de fuentes primarias en las que se basa espuni, consulta referencias.