El registrador de verificadores: la figura que dos ecosistemas inventaron por separado

Convergieron en todo menos en lo que decide

Si abres la especificación de verificación de identidad de Google Wallet y la pones al lado del Blueprint europeo de verificación de edad, la primera impresión es de déjà vu. Los dos hablan OpenID4VP sobre la Digital Credentials API del navegador. Los dos usan credenciales mdoc según ISO/IEC 18013-5, presentadas por el perfil de la 18013-7. Los dos firman la petición como un JAR con ES256 y una cadena X.509, identifican al verificador por el hash del certificado, y exigen que la respuesta vuelva cifrada con una clave efímera generada para esa única transacción.

La convergencia llega hasta un sitio que a mí me sigue pareciendo notable: el esquema de pruebas de conocimiento cero es literalmente el mismo. Google publica su carril ZK sobre longfellow-libzk-v1. El Anexo B del Blueprint europeo evaluó cinco esquemas candidatos, eligió ECDSA Anonymous Credentials de Frigo y shelat, y la implementación de referencia que cita es la misma librería de Google. Dos ecosistemas que no se coordinan acabaron, en la pieza criptográfica más difícil de todas, ejecutando el mismo código.

Y sin embargo no son intercambiables. Ni de lejos.

Porque el protocolo nunca fue la parte difícil. La parte difícil es la pregunta que ningún protocolo responde: ¿en quién confío, y quién decide eso?

Dos preguntas, no una

Se suele hablar del "modelo de confianza" como si fuera una cosa. En verificación de edad son dos, y los dos ecosistemas responden distinto a cada una.

La primera: ¿quién avala la credencial? Es decir, cuando llega una prueba de que alguien es mayor de 18, ¿qué me autoriza a creerla?

En el marco europeo, la respuesta es una cadena que termina en una acreditación. Un proveedor de atestación acreditado emite la credencial; su certificado de firma aparece en una Trusted List europea publicada en formato ETSI TS 119 612 y firmada por la Comisión. El verificador descarga esa lista, comprueba la firma contra un firmante conocido, y solo entonces acepta al emisor. La propiedad importante no es que la lista exista: es que está firmada y es auditable. Cualquiera puede descargarla, verificarla y llevarle la contraria a quien diga que un emisor está dentro.

Conviene deshacer aquí un malentendido frecuente, porque cambia toda la comparación que viene después: el emisor no tiene por qué ser una administración pública. Nada en el marco dice que la credencial de edad la emita quien expide el documento de identidad. Un banco, una operadora, una notaría o una plataforma de identidad pueden emitirla perfectamente, verificando un documento o apoyándose en información que ya tienen y que acredita la edad — un banco sabe la fecha de nacimiento de su cliente desde que lo dio de alta. Lo que el marco fija no es quién emite, sino quién decide que ese emisor cuenta: un estado miembro, mediante un procedimiento de acreditación, y con esa decisión publicada en una lista firmada que cualquiera puede comprobar.

En Google Wallet, la respuesta es un fichero de certificados IACA que publica Google. Y aquí hay un detalle que se pasa por alto y que a mí me parece el más importante de todo el asunto: para el ID Pass — la credencial que Google está desplegando en Europa — el IACA es de Google. La documentación es explícita: salvo Estados Unidos, todos los países usan el mismo certificado IACA para ID Pass. El ancla no es una acreditación pública, ni el estado que expidió el documento del que se deriva la credencial: es la propia empresa que sirve la cartera.

Y la credencial en sí tiene una procedencia distinta. Para dar de alta un ID Pass, el usuario fotografía la página de datos de su pasaporte, lee el chip NFC con el teléfono y pasa una prueba de vídeo-selfie. Es un proceso de verificación documental serio y funciona — está en producción en Reino Unido, Brasil, India, Singapur y Taiwán. Pero es una credencial derivada por el proveedor de la cartera a partir de un documento que el usuario le enseña, no una atestación emitida por la autoridad que expidió ese documento.

A eso se suma la otra vía, que Google anunció en junio: emisores privados. Su primer socio nacional para el aseguramiento de edad en la UE es Sparkasse. Es decir, una caja de ahorros alemana emitiendo una credencial de edad a la cartera de una empresa estadounidense, anclada en el IACA de esa empresa. En términos de despliegue es mucho más rápido que esperar a que veintisiete estados acrediten emisores, y probablemente por eso existe.

Y aquí es donde el malentendido de antes habría estropeado el argumento. Lo interesante no es que Sparkasse sea una empresa privada: esa misma caja de ahorros podría ser un emisor acreditado dentro del marco europeo, emitiendo la credencial de AV, si Alemania optara por esa credencial y la acreditara para ello. Mismo emisor, mismos datos, misma comprobación de edad. Lo que cambia entre un caso y el otro no es quién emite — es quién dijo que ese emisor vale, y si esa decisión se puede consultar. En un caso es un estado miembro por un procedimiento público, y la decisión vive en una lista firmada. En el otro es una empresa, y la decisión vive en su almacén de confianza.

No lo digo como reproche. Es una decisión de diseño perfectamente defendible y tiene una ventaja enorme: no necesitas que veintisiete estados terminen su despliegue para tener algo que funcione hoy. Pero es un tipo de afirmación distinto. Una dice "alguien a quien el Estado X acreditó para esto atestigua que esta persona es mayor de edad, y puedes comprobar la acreditación". La otra dice "alguien a quien nosotros admitimos en nuestro almacén atestigua que lo es, y la admisión no es pública". Ambas pueden ser ciertas, y en las dos el emisor puede ser exactamente la misma empresa. No son la misma frase, y un verificador que las trate como equivalentes está mezclando dos niveles de garantía sin darse cuenta.

Y sin embargo, la criptografía es la misma

Hay un detalle de implementación que cambia cómo se ve esta diferencia, y que me sorprendió al comprobarlo. Uno esperaría que aceptar dos modelos de confianza distintos costara escribir dos verificadores. No es así: la parte criptográfica es idéntica. Un validador de cadenas X.509 recibe un puñado de certificados de confianza en DER y una cadena que comprobar contra ellos, y le da exactamente igual si esos bytes salieron de una Trusted List europea firmada por la Comisión o de un fichero PEM publicado por una empresa. La librería de referencia de mdoc de la OpenWallet Foundation lo dice en su propia firma de función: pide un array de bytes, y nada más.

Así que soportar los dos ecosistemas no es escribir criptografía nueva. La diferencia entera vive aguas arriba del validador, en cómo conseguiste esos bytes. Y ahí no se parecen en nada:

• Procedencia. La Trusted List es un documento firmado. Verificas su firma contra un firmante fijado de antemano y, a partir de ahí, el conjunto de anclas se acredita a sí mismo: puedes rehacer la comprobación sin conexión seis meses después y demostrar qué decía. Un fichero de certificados no lleva firma sobre su contenido; su única procedencia es el TLS con el dominio del que lo descargaste. No hay nada que fijar ni nada que reverificar. Si quieres evidencia, te la tienes que fabricar tú: guardar una copia y su hash, y anotar cuándo la bajaste.
• Estado. Cada entrada de una Trusted List lleva su rol y su estado — este certificado sirve para emitir; este servicio está vigente o retirado. Es revocación del papel, no solo del certificado: un emisor puede dejar de valer sin que su X.509 caduque ni entre en ninguna lista de revocación. Un fichero de certificados es plano. Ahí "revocar" es que alguien quite una línea, y sin volver a descargarlo no te enteras — ni puedes distinguir "ya no está" de "la descarga falló".
• Frescura. La lista dice cuándo caduca como evidencia. El fichero no tiene fecha: una copia rancia y una recién bajada son indistinguibles.

Dicho de otro modo: en un caso la confianza viaja en un documento que se defiende solo; en el otro viaja en un canal, y el canal no deja rastro. Lo caro de aceptar Google no es verificar. Es poder decir después, con pruebas, en qué te basaste para aceptar — y eso hay que construirlo a mano, porque el ecosistema no lo da.

La segunda pregunta: ¿quién avala al verificador? Cuando una cartera recibe una petición de "demuéstrame que eres mayor de 18", ¿cómo sabe que quien pregunta tiene derecho a preguntar?

Antes de responder hay que parar y marcar una frontera que se salta con demasiada facilidad. En Europa no hay un marco, hay dos, y responden a esta pregunta de forma opuesta.

El Blueprint de verificación de edad no registra al verificador. Es el perfil específico de AV, el que está desplegado hoy para comprobar la mayoría de edad. En él, el identificador del verificador es el hash de su propio certificado: autoasertado, sin nadie detrás que lo avale; y el camino de reserva por QR, el que se usa cuando el navegador no expone la API de credenciales, va directamente sin firmar. Nadie acredita a nadie. La cartera no sabe quién pregunta, y el diseño asume que no necesita saberlo, porque la credencial solo puede responder una cosa: un sí o un no sobre la edad. La minimización no viene de autorizar al que pregunta — viene de que la respuesta no sabe decir nada más. No es una carencia del perfil: es el perfil.

El marco EUDI completo sí registra, y es el que aplica cuando la edad no viene de una credencial de AV sino de los atributos del PID, la credencial de identidad de la cartera. Ahí el relying party se registra en su estado miembro y obtiene dos certificados: uno de acceso, que responde a "¿quién establece esta conexión?", y uno de registro, que responde a "¿qué datos puede pedir, con qué base legal y para qué finalidad?". Y no es decorativo: el certificado de registro acota la petición — si el RP pide una credencial que su certificado no autoriza, la cartera lo detecta y avisa al usuario, que decide si sigue adelante; algunos estados miembros han optado por una interpretación estricta y rechazan la petición sin preguntar. Es prevención de sobrepetición escrita en el protocolo, no en la política. Registro público, autoridad identificable, procedimiento administrativo, y derecho a recurso.

La diferencia entre los dos es enorme y conviene no promediarla. Comparar "Europa" con Google sin decir con cuál de los dos permite contar prácticamente cualquier historia.

En Google Wallet, el verificador rellena un formulario de admisión y Google decide. Si le parece bien, añade tu certificado raíz a su almacén de confianza. Es una allowlist privada, gestionada por una empresa, sin publicación ni auditoría externa.

Y ahora la comparación honesta, que es menos cómoda de lo que parecía: en el carril que hoy verifica edad de verdad, el europeo no examina al verificador y el de Google sí. Google mira un formulario y decide; el Blueprint de AV no mira nada, porque resolvió el problema por el otro extremo — acotando lo que la credencial puede decir en lugar de acotando quién puede preguntar. Son dos estrategias legítimas y opuestas: una limita al que pregunta, la otra limita la respuesta. La maquinaria europea de acreditar verificadores existe y está mejor diseñada que un formulario… pero vive en el otro marco, el del PID, que es también donde hay bastante más que un booleano que proteger. Y a día de hoy sigue sin estar operativa: todavía no hay autoridades emitiendo esos certificados en producción.

Y entonces los dos se toparon con el mismo problema

Donde hay puerta, hay cola. Esto vale para el marco EUDI y para Google — no para el Blueprint de AV, que al no registrar a nadie no tiene este problema y tampoco el control que lo causa. Hay millones de servicios que necesitarán comprobar la edad, y ni veintisiete registros nacionales ni un equipo de revisión en Mountain View pueden absorber eso de uno en uno.

Los dos ecosistemas llegaron, por separado, a la misma solución estructural: una capa intermedia que avala a los que están por debajo. Y aquí es donde se ve lo distintos que son.

El marco europeo —el EUDI, insisto, el que registra— la llama intermediario y la tiene reconocida y regulada: es el Topic 44 del ARF. El diseño es elegante: en cada transacción viajan dos certificados. El certificado de acceso del intermediario, que responde a "¿quién está estableciendo esta conexión?", y el certificado de registro del RP final, que responde a "¿en nombre de quién, y está legalmente autorizado a pedir esto?". El intermediario no absorbe la identidad de su cliente: la transporta. El RP sigue registrándose en su país, sigue siendo el responsable de lo que pide, y la cartera puede ver las dos cosas por separado.

Google la llama Verifier Registrar, y el mecanismo es otro: te conviertes en una autoridad de certificación privada dentro del almacén de confianza de Google. Tu raíz entra en la allowlist; tú emites certificados hoja para cada uno de tus clientes. El RP final nunca habla con Google Wallet. Desde fuera, lo que se ve es tu firma.

La diferencia es de carácter, no de forma. En un caso el intermediario es una figura prevista por la norma, con responsabilidades repartidas y trazabilidad de quién pide qué. En el otro es una figura contratada, en la que el registrador se interpone entre Google y el mundo — y asume lo que eso implica.

Lo que implica ser el registrador

Aquí conviene ser concreto, porque las condiciones del programa de Verifier Registrar son públicas y dicen cosas muy específicas. Ninguna es arbitraria: son las que cabría esperar de quien gestiona riesgo a escala global. Pero hay que entenderlas antes de firmar, no después.

Respondes por tus clientes. Textualmente: serás responsable de "all acts, omissions and liabilities" relativas al uso de los datos por parte de tus clientes. Y hay obligación de indemnidad frente a reclamaciones de terceros derivadas del mal uso por tu parte o por parte de tus clientes.

En sentido contrario, el techo es bajo. Para el EEE se contrata con Google Ireland, y la responsabilidad total se limita al mayor de dos importes: diez mil euros, o lo que hayas pagado en los doce meses anteriores. Como el acceso a los datos no se factura, en la práctica el número es diez mil euros. La asimetría es llamativa, aunque no inusual en servicios ofrecidos sin coste directo: quien no cobra por el acceso limita su exposición por él.

El acceso se puede suspender sin preaviso si Google cree razonablemente que hay un incumplimiento. No es una cláusula inusual en términos de servicio, pero cambia lo que puedes prometer: si construyes un SLA sobre un canal que un tercero puede cortar sin avisar, estás vendiendo una disponibilidad que no controlas.

Ley inglesa, tribunales ingleses, y arbitraje LCIA en Londres como alternativa.

Y una asimetría de protección de datos que merece un abogado. Con Google la relación se rige por los Controller-to-Controller Data Protection Terms — responsables independientes. Pero un intermediario que verifica en nombre de sus clientes es, con toda probabilidad, encargado del tratamiento respecto de ellos. Dos sombreros distintos en la misma transacción. Se puede sostener, pero hay que sostenerlo por escrito antes de firmar, no después.

A eso se añade la operativa: certificados separados para cada RP durante el periodo inicial de lanzamiento, con nombre distinguido globalmente único; una lista de revocación que publicas y mantienes tú, con obligación de revocar rápido ante clientes abusivos; y una revisión humana de dos a tres días hábiles por cada cliente nuevo que das de alta. Google reconoce la sobrecarga y dice que estudiará alternativas — menciona hashes de metadatos del RP — después del despliegue inicial.

Merece la pena detenerse en la CRL, porque es lo que más se subestima. Una lista de revocación no es un fichero: es un servicio público cuya caída invalida operaciones de terceros. Tiene uptime, tiene monitorización, tiene un procedimiento de emergencia. Quien piense que ser CA es ejecutar openssl un par de veces al año no ha operado nunca una.

Y aquí vuelve lo de antes, ahora del lado del verificador. En el marco europeo el estado viaja dentro de la lista firmada: si un canal de revocación falla, la lista sigue diciendo la verdad sobre quién está dentro y quién está retirado. En el modelo de Google no hay esa segunda fuente — las anclas del emisor son un fichero sin estado, y la CRL del registrador es el único canal de revocación que existe en toda la cadena. Una CRL caída no degrada la señal: la borra. Eso no hace inviable el modelo, pero sí sube bastante el listón de lo que significa "mantener una lista de revocación".

Y una nota sobre el modelo de negocio: la FAQ de Google es clara en que su modelo y su preferencia es trabajar directamente con los registradores y con sus RPs finales directos, no con modelos de reventa anidada o de intermediarios encadenados. No es una prohibición contractual, pero es una declaración de intenciones que cierra el canal indirecto en la práctica. La marca del agregador, en cambio, es completamente opcional en los metadatos: la marca blanca cabe.

La inversión que creí encontrarme

Lo que sigue es la parte que más veces he reescrito, porque la primera versión me gustaba demasiado como para ser cierta.

Uno esperaría que el marco regulado europeo fuera el estricto en minimización de datos y que el marco privado fuera el laxo, y al leer los requisitos de Google la tentación es concluir que pasa lo contrario. No pasa. Lo que hay no es una inversión: es una diferencia de cuándo se comprueba y quién puede actuar.

Google exige, por cada cliente y manteniéndolo actualizado, un anexo con: los elementos de datos solicitados y el periodo de retención de cada uno, uno por uno; la descripción del propósito y la justificación de la necesidad; enlaces vivos a los términos y la política de privacidad del RP; el territorio aprobado; y una justificación adicional si pides un campo no agregado habiendo uno agregado disponible — si pides la fecha de nacimiento existiendo un age_over_18, tienes que explicar por qué. Es el principio de minimización del RGPD convertido en un formulario que hay que mantener al día y del que no te puedes desviar sin aprobación por escrito.

Suena a algo que Europa no pide. Pero sí lo pide. Para registrarse en el marco EUDI, un RP declara su uso previsto y enlaza las políticas de privacidad del servicio; y el certificado de registro que sale de ahí acota qué credenciales puede pedir y para qué finalidad, hasta el punto de que la cartera detecta y advierte cualquier petición que exceda lo declarado —y, donde el estado miembro ha optado por la lectura estricta, la rechaza directamente—. Eso no lo hace un revisor leyendo un anexo: lo hace el protocolo, en cada transacción, sin que nadie esté mirando.

La diferencia real está en el momento y en quién tiene la palanca. Google examina la declaración antes de dejarte entrar — dos o tres días hábiles por cada cliente nuevo— y su palanca es contractual: cortarte el acceso. En el marco europeo nada obliga al registro a auditar esa declaración en el momento del alta, y en la práctica no suele hacerse; podría hacerse en detalle, pero el control de fondo no vive ahí. Vive después: toda RP registrada tiene detrás una autoridad de control de protección de datos que supervisa su cumplimiento del RGPD. Eso es una figura para la que el modelo de Google no tiene equivalente, y la diferencia de poder no es menor — un equipo de revisión puede dejarte fuera de su ecosistema; una autoridad de control puede inspeccionarte, obligarte a parar y multarte, y sus decisiones se recurren ante un juez.

Así que no es que uno sea estricto y el otro laxo. Uno pone una puerta: control previo, privado, que se pasa una vez y luego confía. El otro pone un supervisor: control posterior, público, que no se pasa nunca del todo porque puede aparecer en cualquier momento. Cada forma falla distinto — la puerta no ve lo que ocurre después de abrirse; el supervisor solo actúa cuando ya ha pasado algo.

Lo que sí me sigue pareciendo más fino en el lado de Google es el detalle por dato: el periodo de retención elemento a elemento y la justificación escrita del campo no agregado. Es una granularidad que la declaración de registro no baja a ese nivel, y que en Europa se resuelve en la responsabilidad del RP frente a su autoridad de control — que es donde el RGPD ya la tenía, con más fuerza pero con menos artefacto.

Y conviene recordar de dónde no hace falta nada de esto: en el carril de AV no hay declaración que hacer, porque solo viaja un age_over_NN. No hay finalidad que acotar ni campo fino que justificar cuando la credencial únicamente sabe decir sí o no. Toda esta maquinaria —la de los dos lados— es la respuesta a un problema que el Blueprint de AV eliminó en el diseño.

Merece la pena decirlo sin triunfalismo, en las dos direcciones: un formulario privado no es control democrático, y la asimetría de poder sigue siendo total, porque quien revisa el formulario también puede suspenderte sin avisar. Pero un control que se aplica todos los días es un control, y llegar antes tiene valor. Hay algo que el lado europeo podría tomar de esa granularidad operativa —el detalle por dato, escrito y mantenido— sin renunciar a un gramo de su fuerza jurídica ni de su supervisión independiente.

Del anuncio a la lista de emisores

El 4 de junio de 2026, en Money 20/20 Europe, Google anunció que el ID Pass llegaría a España, Italia, Francia, Irlanda y Estonia antes de que acabara el verano, junto con una credencial de edad desarrollada con Sparkasse como primer socio nacional para el aseguramiento de edad en la UE.

Hoy es 5 de septiembre. La página pública de emisores soportados lista mDL de once jurisdicciones norteamericanas, e ID Pass de Estados Unidos, Brasil, India, Singapur, Taiwán y Reino Unido. Ni un solo estado miembro de la UE. El único europeo de la lista salió de la Unión hace años.

No lo señalo como pillada: los despliegues de identidad se retrasan, es lo normal, y cinco países a la vez es ambicioso. Lo señalo porque marca dónde hay que mirar. Un anuncio dice qué quiere hacer alguien; una demostración dice que la tubería funciona; la lista de emisores es lo único que determina si un verificador puede aceptar algo hoy. Son tres cosas distintas y se confunden con facilidad, sobre todo cuando la que más circula es la primera.

Así que si estás decidiendo tu estrategia de carteras, el dato que necesitas no está en la nota de prensa. Está en esa lista, y conviene volver a mirarla cada pocas semanas, porque "aceptamos cualquier cartera" significa cosas muy distintas según el mes.

El intermediario ve todas las transacciones

Hay una incomodidad estructural en toda esta arquitectura que conviene decir en voz alta, porque afecta a los dos modelos por igual y porque el que la señala primero es quien tiene derecho a que le crean después.

Si una entidad se sitúa entre muchos servicios y muchas carteras, esa entidad ve todas las transacciones de todos ellos. Aunque la prueba de conocimiento cero sea impecable. Aunque no se guarde ni un dato personal. Aunque la credencial solo revele un booleano.

El Anexo B del Blueprint ya avisa de que la unlinkability no es gratis, y de que un periodo de validez demasiado fino en la atestación puede convertirse en un vector de rastreo. Pero el riesgo del intermediario es de otra clase: no es criptográfico, es posicional. Ver que un dominio pidió una verificación en un instante concreto no identifica a nadie por sí solo. Ver eso mismo para miles de dominios, continuamente, es otra cosa.

La única respuesta defendible es diseñar para no poder correlacionar — no guardar lo que permitiría hacerlo, separar las retenciones, y someterlo a auditoría — en lugar de prometer que no se hará. Y esto no es una crítica al modelo de Google ni al europeo: es una propiedad de cualquier arquitectura con una capa intermedia. Me incluyo sin reservas — cualquier servicio que yo construya en esta posición, espuni incluido, hereda exactamente el mismo problema y la misma obligación. Quien venda privacidad, empezando por mí, tiene el deber de explicar qué ve y de diseñar para no poder correlacionar. No es un señalamiento a nadie; es la regla de la casa para todos los que vivimos en esta capa.

La pregunta abierta

Hace unas semanas escribí que en identidad digital los formatos convergen y la confianza no. Aquello comparaba dos ecosistemas públicos y soberanos, la UE y Suiza, y la conclusión era casi tranquilizadora: dos administraciones tomando decisiones técnicas distintas, ambas de buena fe, y un problema de reconocimiento mutuo que se resolverá cuando alguien firme algo.

Esto es otra cosa. Aquí un lado del contraste es una empresa. Y eso introduce una asimetría que no existía en la comparación anterior: hoy, uno de los dos puede ajustar las reglas con más agilidad que el otro — añadir un requisito de metadatos, cambiar el perfil de certificado, revisar los términos de acceso. Es la contrapartida natural de su mayor velocidad de despliegue, y nada impide que esos términos maduren y se equilibren a medida que el ecosistema se asienta. Pero mientras tanto conviene saber qué se firma.

Al contrario: es un argumento a favor de integrarse con Google Wallet con los ojos abiertos. Google va a tener volumen real en Android mucho antes de que las carteras nacionales lleguen a masa crítica, y un servicio que necesita comprobar edades hoy no puede permitirse esperar. La cuestión no es si integrarse, sino hacerlo sabiendo exactamente qué se firma, y no confundir dos cosas que suenan igual: aceptar cualquier cartera es cobertura de mercado; cumplir eIDAS 2 es otra cosa. Se pueden —y probablemente se deben— querer las dos. No son la misma.

Lo que sí me parece claro es que ser el registrador de otro está dejando de ser una rareza para convertirse en un rol de primera clase en los dos mundos. En uno es una figura prevista por la norma, con responsabilidades repartidas y derecho a recurso. En el otro es un contrato con responsabilidad agregada, techo de diez mil euros y suspensión sin preaviso.

Quien asuma los dos papeles a la vez —y en un ecosistema multi-cartera, alguien tendrá que hacerlo— estará operando simultáneamente bajo dos regímenes que no se parecen en casi nada. No es un proyecto. Es un coste permanente. Y conviene contarlo como tal desde el principio, antes de que se convierta en la sorpresa del segundo año.

---

Este artículo se apoya en documentación pública consultada el 5 de septiembre de 2026: la guía de integración para registradores de verificadores de Google Wallet, sus Condiciones del Servicio, su FAQ de identidad y credenciales digitales, y su página de emisores soportados y certificados IACA; el Blueprint europeo de verificación de edad y su Anexo B sobre pruebas de conocimiento cero; el Architecture and Reference Framework de la EUDI Wallet (Topic 44, intermediarios); y la cobertura pública del anuncio de Google en Money 20/20 Europe del 4 de junio de 2026. Las condiciones comerciales y las listas de emisores cambian; conviene comprobar las fuentes antes de tomar decisiones. Refleja mi propia lectura como ingeniero que trabaja en el lado del relying party de la verificación de edad; no representa a ninguna organización, y no es asesoramiento legal.