Lo que aprendí probando contra una cartera real y la implementación de referencia no podía enseñarme

La ilusión cómoda

Durante semanas, mi verifier de verificación de edad pasó todo lo que le eché. Peticiones de presentación bien construidas, respuestas parseadas, firmas validadas, resultados devueltos. Probado contra la cartera de referencia de verificación de edad de la Comisión Europea, la implementación publicada junto al Age Verification Blueprint. Todo en verde.

Después conseguí acceso de test a AltID — la cartera danesa, y el primer emisor de credenciales de verificación de edad en la Trusted List de producción de la UE — apunté el mismo verifier hacia ella, y la petición fue rechazada de plano antes de que se moviera una sola credencial.

Ese hueco es el tema de este artículo. No porque hubiera nada mal en la implementación de referencia, sino por para qué sirve una implementación de referencia, y qué es lo que discretamente no puede contarte.

Conseguir acceso, porque esto se pregunta mucho

Una nota práctica primero, porque la pregunta que más me hacen sobre AltID es si alguien que no sea danés puede probar contra ella. La respuesta es sí.

La Agencia Danesa de Digitalización ofrece acceso de test a organizaciones: una versión de test de la app de AltID, una herramienta de test que genera peticiones de presentación y — la parte que desbloquea a todos los que están fuera de Dinamarca — ayuda para provisionar un usuario MitID de test, que elimina la necesidad de tener un número CPR danés. La solicitud va a la dirección de contacto de AltID que publican, con el asunto que ellos especifican, desde un correo corporativo. Su documentación de integración cubre el proceso.

Un detalle que conviene saber antes de empezar, porque cambia cuánto trabajo estás asumiendo: AltID no exige registro de relying party para la verificación de edad. El registro es necesario para solicitar la credencial de identidad (PID), no la prueba de edad. Para un caso de uso de verificación de edad, no hay puerta de registro que cruzar.

Dos perfiles, y probablemente quieres el más simple

AltID soporta dos perfiles de OID4VP, y la elección importa más de lo que parece a primera vista.

HAIP — el High Assurance Interoperability Profile — cubre todos los tipos de credencial. Exige que el verifier registre un certificado y firme sus peticiones, obliga a cifrar las respuestas, y requiere flujos same-device con redirect para resistencia a phishing. Es el camino generalista y más pesado.

AVP — el Age Verification Profile de la UE — se limita a la prueba de edad. No exige registro, autentica al verifier por URI, y lleva la petición como parámetros de URL en claro. Existe específicamente para hacer simple el caso de la verificación de edad, y está alineado con el EU Age Verification Blueprint.

Si construyes verificación de edad, AVP es el camino. Menos trabajo, menos piezas móviles, y es el perfil hacia el que converge el ecosistema europeo de verificación de edad. Ninguno de los dos perfiles usa la Digital Credentials API del navegador — AltID no soporta DC API en absoluto. Es OID4VP clásico sobre código QR o enlace en el mismo dispositivo.

El hallazgo de verdad: las implementaciones de referencia son permisivas

Aquí está la parte que no esperaba.

Mi verifier y AltID hablaban el mismo protocolo, usando el mismo perfil, con la misma configuración. El rechazo no era una discrepancia de protocolo. Era que mi petición de presentación contenía un puñado de campos de más — restos y comodidades que no forman parte de la especificación DCQL — y el validador de peticiones de AltID rechazaba el conjunto entero en lugar de ignorarlos.

La cartera de referencia había aceptado esas mismas peticiones sin rechistar, todas las veces, durante semanas.

Ambos comportamientos son defendibles. Una implementación de referencia existe para demostrar que un flujo funciona y para dar a quien implementa algo contra lo que desarrollar; ser tolerante con entradas imperfectas la hace más útil para eso. Una cartera de producción emitida por una autoridad nacional tiene incentivos distintos: la validación estricta de esquema es una propiedad de seguridad, y rechazar cualquier cosa que no case exactamente con la especificación es la elección conservadora correcta.

Pero la consecuencia para quien construye un verifier merece decirse sin rodeos: pasar la implementación de referencia no significa que seas interoperable. Significa que todavía no te han dicho que estás equivocado. La referencia es un suelo, no un techo — y el hueco entre "funciona contra la referencia" y "funciona contra una cartera de producción" es real, silencioso, y solo se descubre probando contra la cosa real.

De quién era la culpa

Merece decirlo con claridad, porque sería fácil presentar a la implementación de referencia como el problema. No lo era.

Los campos de más eran míos. Se habían ido acumulando como se acumulan las cosas durante el desarrollo — una comodidad aquí, un resto de un enfoque anterior allá — y ninguno tenía sitio en una petición conforme a la especificación. AltID hizo bien en rechazarlos. La cartera de referencia simplemente nunca iba a ser quien me lo dijera.

Esa es la asimetría que conviene interiorizar. Un validador permisivo no te da ninguna señal cuando te alejas de la especificación, y alejarse es el estado por defecto de cualquier código en desarrollo activo. No te enteras de que te has desviado hasta que algo estricto mira tu salida. Si lo único estricto que la mira alguna vez es la cartera real de un usuario en producción, ese es un mal sitio para enterarse.

Configurado no es lo mismo que funcionando

Un hábito relacionado hacia el que esto me empujó, y que sugeriría a cualquiera que construya un verifier.

Hay una categoría de comprobaciones — la validación de lista de confianza es la obvia — cuyo modo de fallo es silencioso. Todo devuelve éxito, así que todo parece correcto, y puedes pasar mucho tiempo sin notar que una comprobación no está ejercitando de verdad el camino que crees. Un test positivo no distingue entre "la validación se ejecutó y pasó" y "la validación nunca se ejecutó".

Así que la pregunta que merece hacerse sobre tu propia implementación no es "¿está configurada la validación de lista de confianza?". Es "¿he visto rechazar a un emisor que no está en la lista?". Son preguntas distintas, y solo la segunda es evidencia. Lo mismo aplica a la caducidad, a la validación de firma, y a toda comprobación cuyo trabajo es decir que no: si nunca la has visto decir que no, no sabes que pueda hacerlo.

Qué puedo y qué no puedo afirmar ahora

Siendo preciso con esto, porque la distinción importa y es fácil pasarse.

Lo verificado: el verifier completa una presentación de verificación de edad end-to-end con AltID en el entorno de test de AltID, con la validación de lista de confianza activa. El selective disclosure se comporta según la especificación — la credencial lleva nueve umbrales de edad, la petición solicita uno, y se revela exactamente uno. Ese último punto ya no es una afirmación de diseño; he visto a ocho atributos quedarse ocultos.

Lo que no: esto es un entorno de test, con una credencial de test y un certificado de emisor de desarrollo, no tráfico de producción con usuarios reales. Las pruebas de casos negativos — credenciales expiradas, emisores no confiables, firmas manipuladas — están cubiertas con vectores sintéticos en CI, y sigo trabajando en los casos manuales contra el emisor de test en vivo. "Acepta lo que debe" es solo la mitad de un verifier. La otra mitad es "rechaza lo que debe", y prefiero decirlo cuando haya visto a cada caso hacerlo.

La conclusión práctica

Si construyes verificación de edad para el Artículo 28 del DSA — o estás evaluando a alguien que lo ha hecho — la pregunta que merece hacerse no es "¿funciona?". Es "¿contra qué se ha probado?".

Una implementación validada solo contra una cartera de referencia se ha probado contra algo diseñado para ser indulgente. Los problemas de interoperabilidad viven en el hueco entre eso y las carteras que tus usuarios van a tener de verdad. Hay siete estados miembro front-runner, y cada cartera nacional tendrá su propia estrictez, sus propias rarezas y su propia lectura de la misma especificación. Dinamarca es la primera. No será la última en rechazar algo que la referencia aceptaba.

---

Los puntos técnicos de este artículo se basan en la documentación de integración publicada de AltID (Digitaliseringsstyrelsen), la especificación técnica del EU Age Verification Blueprint y su Age Verification Profile (ageverification.dev), y en mis propias pruebas de integración contra el entorno de test de AltID. Nada de lo aquí expuesto refleja interioridades de los sistemas de ningún empleador; todas las fuentes son públicas.