Identidad digital bien hecha: afirmaciones verificables sin vigilancia

Actualización, 11 feb 2026: Qué rápido ha sido. La verificación de edad de Discord, que funciona con k-id y su socio faceassure, se ha saltado por completo. La herramienta, creada por xyzeva y Dziurwa (con el mérito de amplitudes por el trabajo previo), verifica automáticamente tu cuenta como adulta en Discord, Twitch, Kick, Snapchat y cualquier otra plataforma que use k-id. ¿Cómo? Porque la “estimación facial” de k-id procesa tu cara por completo en el dispositivo y solo manda metadatos al servidor. Así que basta con… mandar metadatos falsos. El servidor no tiene forma de notar la diferencia. Esto no es un fallo. Es la consecuencia inevitable de montar teatro de seguridad en lugar de seguridad de verdad. Si vas a verificar la edad sin una cadena de confianza criptográfica anclada en un proveedor de identidad real, no estás verificando nada. Solo añades una fricción que los usuarios reales odian y que quien tenga ganas de saltársela derrotará en un fin de semana. Todo lo que sigue sigue siendo válido. Sigue leyendo.

Soy australiano. Vivo en el Reino Unido. Mis dos gobiernos tienen la misma responsabilidad en el lío que se está montando ahora mismo.

La Online Safety Act del Reino Unido abrió el melón en julio de 2025. Exige una verificación de edad “altamente eficaz” a cualquier sitio con contenido para adultos (un portal famoso que empieza por P, una web especializada en fans, Reddit, todos), con multas de hasta £18 millones o el 10 % de la facturación global por incumplir.¹ Imgur echó un vistazo a los requisitos y se fue del Reino Unido sin más.² La Online Safety Amendment Act de Australia siguió en diciembre de 2025: prohíbe las redes sociales a menores de 16 años y obliga a las plataformas a demostrar que lo hacen cumplir.³ Y se está extendiendo. Francia aprobó en enero de 2026 una prohibición para menores de 15.⁴ España anunció la suya hoy, para menores de 16, con “barreras reales que funcionen, no solo casillas para marcar”.⁵ Se espera que la de Dinamarca salga adelante a mediados de 2026. Grecia está redactando la suya. La Ley de Servicios Digitales de la UE ya exige protecciones adecuadas a la edad en todo el bloque.⁶

Todas las grandes democracias (salvo la de la libertad) llegan a la misma conclusión: las plataformas necesitan saber qué edad tienen sus usuarios. Y el instinto es correcto. Tenemos que proteger a las mentes en desarrollo de contenido dañino. Las pruebas sobre salud mental adolescente y redes sociales sin límites son demoledoras, y el statu quo en el que un niño de 12 años se declara mayor marcando una casilla ha sido una farsa durante veinte años.

Pero ahí va la cosa. Todas las implementaciones hasta ahora se han diseñado alrededor de la pregunta equivocada. Los gobiernos preguntan “¿cómo identificamos a las personas?” cuando deberían preguntar “¿cómo verificamos afirmaciones sin identificar a nadie?”

El resultado es un panorama en el que verificar la edad significa subir una foto de tu pasaporte a un servicio de terceros y confiar en que no le hackeen. O pasar tu cara por un modelo de IA que adivina tu edad a partir de la estructura ósea, que es vigilancia biométrica con otro nombre. El enfoque de la Online Safety Act hizo que el uso de VPN se disparara más de un 1400 % el primer día de aplicación, porque los adultos decidieron, con bastante lógica, que preferían enrutar su tráfico por Irlanda a darle su carné de conducir a una web especializada en fans.

El gobierno debería mantenerse muy lejos de tus asuntos. Pero las empresas deberían poder confiar en que no las harán responsables cuando alguien se salte la verificación de edad. Un chaval de 14 años con una barba frondosa puede engañar a la estimación facial de hoy. Una tarjeta de crédito prestada derrota el control de pago. Una VPN derrota la geovalla sin despeinarse.

Así que vamos a ver: ¿se puede arreglar este desastre?

Sí.

Ya usas casi toda esta tecnología

Esto es lo que hace tan exasperante la situación: las piezas para una verificación de identidad que respete la privacidad no son un proyecto de investigación lejano. Están funcionando en tu móvil ahora mismo… mientras lees esto.

Cada vez que entras en una web y esta te reconoce sin pedirte otra vez la contraseña, hay muchas probabilidades de que un JSON Web Token (JWT) esté haciendo el trabajo duro.⁷ Un JWT es solo un bloque de información firmado. Tiene tres partes: una cabecera que dice cómo se hizo (firmado), una carga útil llena de “afirmaciones” (quién eres y qué tipo de saco de carne eres) y una firma que demuestra que nadie ha toqueteado nada.

Esta pinta tiene la carga útil de un JWT típico cuando entras, por ejemplo, en tu banco:

{
  "sub": "user_38291",
  "name": "Will Hackett",
  "email": "will@example.com",
  "iat": 1706918400
}

¿Ves el campo sub? Es un identificador único. Así sabe el banco que eres tú. Y eso está bien para la banca, porque la ley les obliga a saber quién eres. Pero fíjate en lo que hace ahora cada sistema de verificación de edad: coge este mismo patrón y le mete toda tu identidad con calzador solo para responder a la pregunta “¿esta persona tiene edad suficiente?”

Es como pedirle el pasaporte a alguien porque quieres saber si prefiere té o café.

¿Y si el token fuera así?

{
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "iat": 1706918400
}

Sin sub. Sin nombre. Sin email. Sin fecha de nacimiento. Solo las respuestas a las preguntas que importan de verdad, firmadas por alguien en quien confías. El servicio pregunta “¿eres mayor de 18?” y recibe un true criptográfico. Nunca llega a saber tu nombre, tu cumpleaños, tu dirección ni que eres un australiano de 30 y pico años que vive en Londres y sigue comiendo queso a pesar de lo que le hace.

Ese es todo el concepto. El resto de este artículo trata de hacerlo realidad.

Cómo funcionan las firmas (sin necesitar un máster en matemáticas)

Un token firmado no sirve de nada si no puedes comprobar quién lo firmó. Aquí entran los JSON Web Key Sets (JWKS).⁸ Es un nombre rimbombante para una idea sencilla: quien firma publica su clave pública en una URL, y cualquiera que reciba un token firmado puede comprobarlo con esa clave.

{
  "keys": [{
    "kty": "EC",
    "kid": "uk-gov-age-verification-2026",
    "use": "sig",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
  }]
}

Supón que el gobierno del Reino Unido publica una de estas en gov.uk/.well-known/jwks.json. Ahora, cuando una web especializada en fans recibe un token de verificación de edad que dice que eres mayor de 18, no tiene que fiarse de ti. No tiene que llamar al gobierno. Descarga la clave pública, comprueba la firma, y o las matemáticas cuadran o no cuadran. Sin llamar a casa. Sin llamada a una API. Sin “voy a consultarlo con HMRC (Hacienda)”. La clave pública es pública. La firma son matemáticas. Listo.

Así es como ya funciona cualquier login con OAuth. Cuando pulsas “Iniciar sesión con Google”, la web en la que entras no llama a Google para ver si tu token es legítimo. Coge el JWKS que Google tiene publicado y verifica la firma en local.

Llevamos más de una década haciendo esto. La infraestructura está ahí, aburrida, esperando.

Espera un poco, impaciente… ahora llegamos a lo de la privacidad.

¿Y si solo enseñamos parte del token?

Los JWT normales tienen un problema: la firma cubre toda la carga útil. No puedes arrancar los campos que no quieres compartir sin romper la firma. Si el gobierno firma un token con tus tramos de edad, el hash de tu nombre y tu plantilla biométrica, tienes que presentarlo entero o nada.

Aquí entran los JWT de divulgación selectiva (SD-JWT).⁹ El concepto es de una sencillez gloriosa. El emisor firma la credencial completa, pero cada afirmación tiene su propia divulgación. El titular, que eres tú con tu móvil, puede elegir qué afirmaciones revela. Las demás quedan ocultas, pero la firma sigue verificándose.

Así que el gobierno te emite esto:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_13": true,
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "name_hash": "sha256:a1b2c3d4...",
  "biometric_template": "...",
  "nationality": "AU"
}

Pero cuando la web especializada en fans pide la verificación de edad, tu dispositivo presenta solo esto:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_18": true
}

La firma sigue cuadrando. La web obtiene su respuesta. Y nunca llega a saber tu nombre, tu nacionalidad ni el dato, francamente embarazoso, de que aún no tienes 21 años en cualquier jurisdicción a la que todavía le importe eso.

Las credenciales verificables de W3C van aún más lejos con las pruebas de conocimiento cero, métodos criptográficos que te permiten demostrar que una afirmación es cierta sin revelar los datos de fondo.¹⁰ “¿Esta persona es mayor de 18?” deja de ser una divulgación de datos y se convierte en una prueba matemática. La web no recibe "over_18": true. Recibe una prueba de que la afirmación es cierta, sin ningún dato adjunto.

Es como un portero que, de algún modo, puede verificar tu edad mirando un sobre cerrado sin abrirlo. Los criptógrafos son gente rara y maravillosa.

Cómo debería funcionar esto en tu móvil

Vale, juntémoslo todo. Te prometo que es menos complicado que el proceso actual de subir un selfi sosteniendo tu pasaporte a un servicio de verificación de terceros que quizá el año que viene compre una empresa de la que nunca has oído hablar.

Paso 1: consigue tu credencial (una vez). Tu dispositivo ofrece un marco para gestionar afirmaciones verificables. Te autenticas una vez con el proveedor de identidad de tu gobierno, en el dispositivo. En Estonia, es tu eID. En la UE, a finales de 2026, será tu cartera EUDI.¹¹ En el Reino Unido, podría ser GOV.UK One Login o lo que acabe sustituyéndolo. El IdP del gobierno emite una credencial verificable a tu dispositivo (tramos de edad, hash del nombre, plantilla biométrica), firmada con la clave del gobierno y verificable contra su endpoint JWKS publicado.

Vive en el enclave seguro de tu dispositivo. Lo haces una vez. Luego te olvidas.

Paso 2: la plataforma la envuelve. Tu proveedor de plataforma (Apple, Google) actúa como emisor proxy. Coge la credencial firmada por el gobierno y la reemite con doble firma: la original del gobierno más la propia de la plataforma. Un servicio verificador ya puede confirmar dos cosas: que la afirmación viene de un IdP gubernamental real y que se presenta a través de una plataforma legítima. Y lo crucial: ni el gobierno ni la plataforma saben ante qué servicio la presentas. El gobierno ve “Apple ha pedido una credencial”. Apple ve “se ha guardado una credencial”.

Ninguno ve “Will está intentando entrar en una web especializada en fans a las 2 de la madrugada de un martes”. Lo cual es importante. Para mí no, personalmente… pero en general.

Paso 3: responde preguntas, no peticiones de datos. Cuando un servicio necesita verificar una afirmación, el intercambio es así:

Fans specialist → Your device: "Is this user over 18?"
Your device → Secure Enclave: [biometric check, signature generation]
Your device → Fans specialist: { "over_18": true, "sig": "..." }

En este caso “Fans specialist” es… el servicio al que intentas acceder…

El servicio hace una pregunta. Tu dispositivo la responde. El servicio recibe un sí o no criptográfico. Nada más. No “¿cuál es tu fecha de nacimiento?” sino “¿eres mayor de 18?”. No “¿cómo te llamas?” sino “¿coincide este hash SHA-256?”. No “enséñame la cara” sino “¿pasa la comprobación biométrica del dispositivo?”

Para verificar el nombre, un servicio envía un hash (SHA-256 del nombre, los segundos nombres y los apellidos) y la credencial devuelve si coincide. El servicio nunca ve tu nombre real. Para verificar la foto, la credencial incluye una plantilla biométrica (una representación matemática, no una foto). La comprobación se ejecuta en local, en tu dispositivo. El resultado, coincide o no coincide, se firma y se devuelve. Los datos biométricos nunca salen de tu dispositivo. Nunca.

Estonia clavó la arquitectura. Lástima del alcance.

Ya he escrito antes sobre el sistema de identidad digital de Estonia.¹² Llevan desde 2002 con eID nacionales, y X-Road es la columna vertebral de interoperabilidad que conecta a más de 450 organizaciones.¹³ Todos los ciudadanos mayores de 15 años tienen una identidad digital. El 99 % de los servicios públicos está en línea. El sistema ahorra, según las estimaciones, un 2 % del PIB al año.¹⁴ Es de verdad impresionante. Si alguna vez quieres sentirte mal por GOV.UK, pasa una tarde leyendo cómo hacen los estonios la declaración de la renta.

Pero el sistema de Estonia es un ecosistema cerrado. Funciona de maravilla para los servicios estonios (gobierno, banca, sanidad, impuestos) porque toda la pila es estonia. No puedes usar tu eID estonio para verificar tu edad en Instagram, e Instagram no tiene ninguna razón para integrarse con X-Road por un país de 1,3 millones de habitantes. Normal.

La Cartera de Identidad Digital de la UE, obligatoria bajo eIDAS 2.0 para finales de 2026, está pensada para cerrar esa brecha.¹⁵ Cada Estado miembro debe ofrecer al menos una cartera EUDI. Las plataformas en línea de muy gran tamaño deben aceptarla para la autenticación reforzada. La cartera usa credenciales verificables de W3C con divulgación selectiva integrada.¹⁶ Esto se acerca más al modelo correcto. Pero sigue planteando la cartera como una herramienta de identidad en lugar de una herramienta de afirmaciones. El cambio que hace falta es pasar de “demuestra quién eres” a “responde a esta pregunta concreta”. Es una distinción sutil, pero es todo el juego.

Apple y Google están al 90 % del camino

Esto no es solo un problema de los gobiernos. Los proveedores de plataforma tienen que construir la capa de integración, y la buena noticia es que casi sin querer ya han construido la mayor parte.

Apple gestiona el Secure Enclave, un procesador aislado por hardware y diseñado específicamente para operaciones criptográficas y datos biométricos.¹⁷ Las passkeys, basadas en el estándar FIDO2/WebAuthn, ya usan exactamente esta infraestructura para autenticarse sin contraseña.¹⁸ La clave privada nunca sale del dispositivo. La verificación biométrica ocurre en local. El servidor solo ve una prueba criptográfica. ¿Te suena? Es el mismo patrón.

Extender esto a afirmaciones verificables es, en términos de arquitectura, sencillo. Apple ofrece un marco. Te autenticas con el IdP de tu gobierno a través de ese marco. La credencial se guarda en el Secure Enclave junto a tus passkeys. Cuando un servicio pide una afirmación, el flujo es idéntico al de una autenticación con passkey: comprobación biométrica en el dispositivo y prueba criptográfica enviada al servidor. El servicio sabe que la afirmación es válida. No sabe quién eres. Android tiene capacidades equivalentes con StrongBox y el Trusted Execution Environment.

Los fabricantes de navegadores tienen que extender WebAuthn o crear un estándar paralelo para verificar afirmaciones. Una web debería poder pedir una afirmación verificada tan fácilmente como pide una passkey. Mismo patrón de API. Misma experiencia de usuario. Mismo modelo de seguridad. Las tuberías existen. Solo hace falta que alguien las conecte. Dado que Apple, Google y la FIDO Alliance ya han demostrado que pueden coordinarse con las passkeys, lo cual fue en sí mismo un pequeño milagro de cooperación corporativa, esto no es tan descabellado como suena.

Lo que nadie llega a ver

Voy a ser concreto con las garantías de privacidad, porque aquí es donde se caen la mayoría de las propuestas de identidad digital y la gente empieza, con razón, a murmurar sobre estados de vigilancia.

Tu gobierno nunca sabe qué servicios usas. El proveedor de plataforma hace de proxy de las peticiones al IdP del gobierno con sus propias claves. El gobierno ve “Apple ha pedido una credencial”. No ve “Will ha visitado una web especializada en fans”. Esto importa.

Los servicios nunca ven tus datos. Reciben respuestas criptográficas a preguntas concretas. No tu nombre. No tu fecha de nacimiento. No tu foto. Un sí o un no firmado por una cadena de emisores de confianza. Eso es todo.

Sin identificadores únicos por defecto. La credencial contiene afirmaciones, no identificadores. No hay un ID de usuario que los servicios puedan cruzar entre plataformas. Eres un conjunto de hechos verificados, no una entidad rastreable. Puedes demostrar que eres mayor de 18 en cincuenta webs distintas y ninguna puede saber que es la misma persona. Prueba a hacer eso con la subida de un pasaporte.

Para los servicios que de verdad necesitan identificarte (banca, fuerzas del orden, sectores regulados), el sistema admite una clase especial de credencial con un identificador emitido por el gobierno. Pero ese identificador solo puede resolverse cuando cooperan a la vez el proveedor de plataforma y el gobierno, con un mecanismo de división de claves que exige a ambas partes. Una clave sola no sirve de nada. Eso hace que la vigilancia masiva sea estructuralmente imposible y mantiene la identificación legítima para los casos de uso regulados. Es el equivalente criptográfico de necesitar dos llaves para lanzar un misil nuclear, solo que en vez de acabar con el mundo estás verificando la identidad de alguien para una solicitud de hipoteca. Mucho menos dramático. Las mismas matemáticas.

Todo ocurre en el dispositivo. Las claves del verificador nunca salen del enclave seguro. Ningún servidor central procesa tus datos biométricos. Ningún servicio en la nube ve tus credenciales del gobierno. La prueba se genera en local y se transmite al servicio. Nada más se mueve.

Lo que tiene que pasar

La tecnología está lista. Los estándares existen. El hardware está desplegado en miles de millones de dispositivos. Lo que falta es la voluntad de coordinarse que, tratándose de gobiernos, proveedores de plataforma y organismos de estándares, debería llevar solo… seamos optimistas y digamos cinco años… o cien en el Reino Unido.

Los gobiernos tienen que publicar las claves de sus proveedores de identidad y emitir credenciales verificables que admitan divulgación selectiva. Estonia ya ha hecho lo difícil. La UE obliga a tener carteras para 2026. El Reino Unido estudia una identidad digital. Australia está… bueno, Australia intenta averiguar cómo impedir que niños de 14 años se abran cuentas de TikTok, algo que quizá se beneficiaría de contar con un sistema decente de verificación de edad en lugar de limitarse a amenazar a las plataformas con multas. Los compromisos de infraestructura están en marcha. Solo falta que alguien consiga que hablen entre sí.

Los proveedores de plataforma tienen que construir la capa de marco: gestión de credenciales en el dispositivo, emisión por proxy e integración con el enclave seguro para verificar afirmaciones. Apple y Google están al 90 % con las passkeys. El 10 % restante es extender la misma arquitectura a las afirmaciones verificables. Dado que a las dos empresas les encantaría ser las guardianas de tu identidad digital (y cobrar una modesta tarifa por el privilegio), sospecho que el incentivo de negocio existe.

Los fabricantes de navegadores tienen que extender WebAuthn o crear un estándar paralelo para verificar afirmaciones. Una web debería poder pedir una afirmación verificada tan fácilmente como pide una autenticación con passkey. Mismo patrón de API. Misma experiencia de usuario. Mismo modelo de seguridad.

Y los servicios tienen que dejar de pedir documentos y empezar a hacer preguntas. “¿Este usuario es mayor de 16?” es una pregunta de sí o no. No debería exigir un pasaporte. No debería exigir un selfi. No debería exigir subir una foto de tu carné de conducir a una empresa con sede en una jurisdicción que no sabes ni escribir. Exige un único booleano firmado, verificado contra una clave pública publicada.

Llevamos veinte años construyendo sistemas de identidad que tratan la vigilancia como una función. Es hora de construir uno que trate la privacidad como arquitectura.

La próxima vez que alguien te pida que subas tu pasaporte para demostrar que tienes edad de mirar memes, recuerda: la tecnología para hacerlo bien ya existe. Lleva una década probada en batalla. Está funcionando en tu móvil ahora mismo. Lo único que nos frena es lo mismo que frena a la mayoría de las buenas ideas en tecnología: conseguir que tres grupos distintos de gente que no se caen especialmente bien se pongan de acuerdo en un estándar.

Así que, básicamente, cualquier día de estos…

UK Online Safety Act 2023 ↩
The Register: Imgur exits the UK as parent company faces fine. Bloqueó geográficamente a todos los usuarios del Reino Unido desde el 30 de septiembre de 2025 en lugar de cumplir los requisitos de verificación de edad de la Online Safety Act ↩
Australian Government eSafety Commissioner: Social Media Age Restrictions ↩
Al Jazeera: French MPs approve law seeking ban on social media for children below 15. Aprobada en enero de 2026 por 116 votos a 23 ↩
Euronews: Spain to ban social media platforms for children under 16. Anunciada el 3 de febrero de 2026 en la World Government Summit ↩
European Commission: The Digital Services Act ↩
IETF RFC 7519: JSON Web Token (JWT) ↩
IETF RFC 7517: JSON Web Key (JWK) ↩
IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC) ↩
W3C: Verifiable Credentials Data Model v2.0 ↩
European Commission: European Digital Identity. Obliga a todos los Estados miembros a ofrecer carteras EUDI a finales de 2026 ↩
Will Hackett: Reclaiming the commons: the case for an accountable internet ↩
e-Estonia: X-Road interoperability platform. Conecta a más de 450 organizaciones mediante un intercambio de datos descentralizado y de código abierto ↩
University of Liverpool: As the UK plans to introduce digital IDs, what can it learn from pioneer Estonia? ↩
eIDAS 2.0 Regulation (EU) 2024/1183. Entró en vigor en mayo de 2024, con carteras previstas para finales de 2026 ↩
W3C: Verifiable Credentials Implementation Guidelines, Selective Disclosure and Zero-Knowledge Proofs ↩
Apple: About the security of passkeys. Las passkeys usan el Secure Enclave para generar claves y verificar datos biométricos ↩
FIDO Alliance: Passkeys. Estándar FIDO2/WebAuthn para autenticación sin contraseña ↩