AAVP — Especificación Técnica del Protocolo

v0.5.0 — Borrador Inicial — Febrero 2026

Este documento describe la arquitectura, los fundamentos criptográficos y el modelo de seguridad del Anonymous Age Verification Protocol. Para una introducción accesible, consultar README.md.

Índice

• 1. Arquitectura del Protocolo
• 2. Estructura del Token AAVP
• 3. Rotación de Tokens
• 4. Fundamentos Criptográficos
• 5. Modelo de Confianza Descentralizado
• 6. Flujo Operativo Detallado
• 7. Modelo de Amenazas
• 8. Trabajo Futuro y Líneas Abiertas
• Glosario

1. Arquitectura del Protocolo

1.1 Roles del Protocolo

AAVP define tres roles con responsabilidades diferenciadas. El diseño garantiza que ninguno necesita confiar ciegamente en los otros: la verificabilidad criptográfica sustituye a la confianza institucional.

Device Agent (DA)

El Device Agent es un rol abstracto del protocolo: un componente de software que reside en el dispositivo del menor y es responsable de generar, custodiar y rotar los tokens de edad.

Qué es: Una pieza de software que implementa la especificación AAVP para la generación y gestión de tokens. Es el único componente del sistema que conoce la configuración real de franja de edad.

Qué NO es: El Device Agent no es sinónimo de “control parental”. Es un rol del protocolo que puede ser implementado por distintos vehículos:

La separación entre el rol (Device Agent) y su vehículo de implementación es deliberada: permite que el ecosistema evolucione sin modificar el protocolo. Hoy, el vehículo más probable es el software de control parental existente; mañana, podría ser un componente nativo del sistema operativo.

Responsabilidades del DA:

• Generar pares de claves locales en almacenamiento seguro (Secure Enclave, TPM, StrongBox).
• Generar tokens efímeros con la franja de edad configurada.
• Obtener firma parcialmente ciega del Implementador: los metadatos públicos (age_bracket, expires_at) son visibles al IM, pero el nonce permanece cegado.
• Presentar tokens firmados al Verification Gate.
• Rotar tokens antes de su expiración.
• Proteger la configuración de franja mediante PIN parental o mecanismo equivalente a nivel de SO.

Verification Gate (VG)

Endpoint dedicado de la plataforma digital que actúa como puerta de entrada al servicio. Valida el token AAVP y establece una sesión interna con la marca de franja de edad.

Responsabilidades del VG:

• Exponer un endpoint estándar (.well-known/aavp) o registro DNS para anunciar soporte AAVP.
• Validar la firma criptográfica del token contra las claves públicas de Implementadores aceptados.
• Verificar el TTL del token.
• Extraer la franja de edad y establecer una sesión interna.
• Rechazar tokens expirados, malformados o firmados por Implementadores no confiables.

Implementador (IM)

Empresa u organización que desarrolla software que actúa como Device Agent, conforme al estándar AAVP.

Responsabilidades del IM:

• Publicar su clave pública en el registro de Implementadores.
• Mantener código auditable (preferentemente open source).
• Proveer servicio de firma parcialmente ciega al Device Agent.
• Cumplir con la especificación abierta.

1.2 Modelo de Puerta de Entrada (Verification Gate)

Un enfoque ingenuo enviaría la credencial de edad en cada petición HTTP, exponiéndola continuamente a posibles interceptaciones. AAVP adopta un modelo diferente: la puerta de entrada.

El token de edad solo viaja una vez por sesión, durante un handshake inicial dedicado. Después, la plataforma trabaja con su propio sistema de sesiones.

Idea clave: El token de edad nunca convive con el tráfico regular de la aplicación. Es un canal separado, un handshake puntual. Después, la información “este usuario es menor” es un flag interno de la plataforma, completamente desacoplado del token original.

Ventajas del modelo de puerta de entrada:

• Superficie de ataque reducida: el token de edad solo viaja una vez por sesión, no en cada request.
• Separación de contextos: la información de edad nunca convive con el tráfico de datos de la aplicación.
• Compatibilidad: las plataformas ya gestionan sesiones; AAVP solo añade un paso previo.
• Ventana temporal mínima para MITM: interceptar el handshake inicial requiere comprometer TLS con certificate pinning en una ventana muy breve.

2. Estructura del Token AAVP

El token es una estructura criptográfica de tamaño fijo (331 bytes) diseñada para ser mínima. Cada campo tiene una justificación específica y supera el test de minimalismo de datos del protocolo.

Formato binario

El token tiene un formato binario fijo de 331 bytes, sin separadores ni metadatos de codificación. La canonicalización está implícita en el formato: los campos se concatenan en el orden especificado con offsets determinísticos.

Offset  Tamaño  Campo                Visibilidad
0       2       token_type           Público
2       32      nonce                Cegado (oculto al IM durante emisión)
34      32      token_key_id         Público
66      1       age_bracket          Metadato público (0x00-0x03)
67      8       expires_at           Metadato público (uint64 BE, precisión 1h)
75      256     authenticator        Firma parcialmente ciega (RSAPBSSA-SHA384)
---
Total: 331 bytes (fijo)

Todas las implementaciones conformes deben producir tokens de exactamente 331 bytes. Un token de tamaño diferente es inválido.

Metadatos públicos vs. contenido cegado

El token AAVP utiliza firmas parcialmente ciegas (Partially Blind Signatures). Esto implica una distinción entre dos tipos de contenido dentro del token:

• Metadatos públicos (age_bracket, expires_at): visibles al IM durante el proceso de firma. El IM los utiliza para derivar una clave de firma específica via HKDF. Son parte del contrato visible entre el DA y el IM.
• Contenido cegado (nonce): oculto al IM durante la emisión. Solo el DA y el VG conocen su valor. El cegamiento criptográfico garantiza que el IM no puede leerlo.

El IM conoce la franja de edad del token que firma, pero no puede vincular esa información con la identidad del usuario que la solicita. Dentro de una misma franja, todos los tokens son indistinguibles para el IM. Esto preserva la unlinkability: la franja de edad no es un dato personal, es la señal mínima que el protocolo necesita transmitir.

Esta arquitectura es aceptable porque:

1. La franja de edad es precisamente la señal que el protocolo transmite. No es información adicional.
2. El IM no obtiene nada que el VG no obtenga también al verificar el token.
3. El IM puede actuar como segunda barrera contra la suplantación de age_bracket, verificando coherencia con la configuración del DA.

Test de minimalismo de los campos nuevos

Los campos token_type y token_key_id son adiciones respecto a versiones anteriores de la especificación. Ambos superan el test de minimalismo de datos:

• token_type: necesario para la agilidad criptográfica (migración post-cuántica). Su valor es idéntico para todos los tokens del mismo esquema. No permite fingerprinting individual.
• token_key_id: necesario para que el VG identifique la clave de verificación sin probar todas las claves conocidas. Derivado de la clave pública del IM (no del usuario). Idéntico para todos los tokens del mismo IM.

Campos explícitamente excluidos

El token no contiene y no puede contener:

• Identidad del usuario
• Identificador del dispositivo
• Dirección IP
• Localización geográfica
• Versión del software
• Sistema operativo
• Timestamp de emisión (issued_at): eliminado porque la frescura se gestiona con expires_at grueso, y un timestamp de emisión con jitter es una superficie innecesaria de fingerprinting
• Ningún otro dato que permita correlación o rastreo

Cada dato adicional es un vector potencial de fingerprinting y debe justificarse rigurosamente antes de incluirse en futuras versiones del protocolo.

3. Rotación de Tokens

Incluso sin datos personales, un token estático podría convertirse en un pseudoidentificador persistente si se reutiliza. Por ello, AAVP implementa rotación obligatoria:

• Tiempo de vida máximo (TTL): Cada token tiene una validez definida por expires_at, recomendándose entre 1 y 4 horas. El VG valida expires_at contra su propio reloj.
• Precisión gruesa de expires_at: El valor de expires_at se redondea a la hora completa más cercana. Esto implica que todos los tokens emitidos en la misma hora comparten el mismo valor de expiración, lo que incrementa el anonymity set y dificulta la correlación temporal.
• Rotación proactiva: El Device Agent puede generar un nuevo token antes de la expiración para mantener la continuidad de la sesión.
• No vinculabilidad (unlinkability): Dos tokens consecutivos del mismo dispositivo no son correlacionables entre sí. Cada token es criptográficamente independiente del anterior.

4. Fundamentos Criptográficos

4.1 Firmas Parcialmente Ciegas (Partially Blind Signatures)

El mecanismo central de AAVP para desacoplar la identidad del usuario de la señal de edad es el uso de firmas parcialmente ciegas, una evolución de las firmas ciegas propuestas por David Chaum en 1983.

Analogía: Un sobre con papel carbón y una ventanilla transparente. El firmante estampa su firma sobre el sobre cerrado: ve a través de la ventanilla la franja de edad (metadato público), pero el resto del contenido permanece oculto.

Esquema elegido: RSAPBSSA-SHA384 (RSA Partially Blind Signature Scheme with Appendix), basado en RFC 9474 y draft-irtf-cfrg-partially-blind-rsa. Este esquema permite que el IM vea los metadatos públicos (age_bracket, expires_at) mientras el nonce permanece cegado.

Derivación de clave por metadato: El IM tiene una sola clave maestra (sk, pk). Para cada combinación de metadatos públicos (age_bracket, expires_at), se deriva automáticamente un par de claves (sk’, pk’) via HKDF. El VG, que conoce la clave pública maestra y los metadatos del token, realiza la misma derivación para verificar. Esto vincula criptográficamente los metadatos a la firma sin revelar el contenido cegado.

Resultado: El Implementador conoce la franja de edad pero no puede vincular un token firmado con el DA que lo solicitó. Dentro de la misma franja, todos los tokens son indistinguibles para el IM. La franja no es un dato personal: es la señal que el protocolo transmite.

Esquema principal y alternativas:

• RSAPBSSA-SHA384 (RFC 9474 + draft-irtf-cfrg-partially-blind-rsa) — Esquema elegido por AAVP.
• Blind BLS Signatures — Alternativa futura por tamaño de firma reducido (48 bytes). Sin RFC publicado.
• ZKP (Bulletproofs) — Complemento para la verificación inicial de edad contra un documento oficial.

4.2 Pruebas de Conocimiento Cero (ZKP)

Como alternativa o complemento a las firmas ciegas, AAVP contempla el uso de pruebas de conocimiento cero (Zero-Knowledge Proofs).

Un ZKP permite demostrar una afirmación — “mi edad está dentro de la franja X” — sin revelar ningún dato adicional. Esto es especialmente útil en escenarios donde la verificación inicial de la edad se realiza contra un documento oficial: el ZKP demostraría que la fecha de nacimiento cumple el criterio de franja sin exponer la fecha, el nombre ni ningún otro campo del documento.

Esquemas candidatos:

• zk-SNARKs (Groth16, PLONK)
• zk-STARKs (sin trusted setup)
• Bulletproofs (para range proofs sobre edad)

4.3 Prevención de Fingerprinting

Cada campo del token está diseñado para minimizar la información que podría usarse para identificar o rastrear al usuario:

5. Modelo de Confianza Descentralizado

5.1 Confianza sin Autoridad Central

AAVP rechaza explícitamente el modelo de Autoridad de Certificación centralizada. La centralización de la certificación crea:

• Incentivos perversos: la entidad central adquiere poder de veto.
• Objetivo prioritario: de presión política y ataques.
• Punto único de fallo: cuya compromisión invalida todo el sistema.

AAVP adopta un modelo de confianza distribuida, inspirado en DMARC/DKIM para autenticación de correo electrónico.

Modelo centralizado (rechazado):

Modelo AAVP (adoptado) — cada plataforma decide en quién confiar:

5.2 Mecanismos de Confianza

5.2.1 Estándar abierto y verificable

Cualquier organización puede implementar AAVP. Sus tokens son verificables criptográficamente por cualquier plataforma que también implemente el estándar. No se necesita permiso de ningún tercero. La confianza proviene de la verificabilidad matemática, no de una autorización institucional.

5.2.2 Código auditable

El estándar recomienda firmemente — y la regulación podría exigir — que las implementaciones del Device Agent sean de código abierto o, como mínimo, auditables por terceros independientes. Esto es análogo a los logs de Certificate Transparency: la comunidad puede verificar que el software cumple con la especificación.

5.2.3 Registro público de Implementadores

Se propone un registro público descentralizado (potencialmente basado en un log transparente) donde los Implementadores publican sus claves públicas y declaran conformidad con el estándar.

Importante: Esto no es una autoridad de aprobación. Es un directorio público auditable, abierto a cualquiera.

5.2.4 Confianza por reputación

Las plataformas deciden individualmente en qué Implementadores confían, del mismo modo que los navegadores deciden en qué CAs confían para TLS. No hay una decisión centralizada, sino múltiples decisiones independientes que tienden a converger.

5.3 Analogía con DMARC/DKIM

6. Flujo Operativo Detallado

6.1 Configuración Inicial (una sola vez)

Este paso lo realizan los padres o tutores. Es el único momento que requiere intervención humana consciente.

1. Los padres activan la funcionalidad AAVP en el dispositivo del menor. El vehículo puede ser un sistema de control parental, una configuración nativa del SO, u otro software conforme.
2. El software que actúa como Device Agent genera un par de claves locales en el almacenamiento seguro del dispositivo (Secure Enclave en iOS, StrongBox/TEE en Android, TPM en Windows/Linux).
3. El DA establece una conexión única con el servicio de firma del Implementador para obtener la capacidad de firma parcialmente ciega.
4. Se configura la franja de edad correspondiente al menor.

6.2 Acceso a una Plataforma (cada sesión)

Este proceso es completamente transparente para el usuario:

1. El usuario abre la aplicación o accede al sitio web.
2. El Device Agent detecta que la plataforma soporta AAVP (vía registro DNS _aavp o endpoint .well-known/aavp).
3. El DA genera un token efímero, ciega el nonce, envía el mensaje cegado junto con los metadatos públicos (age_bracket, expires_at) al Implementador para firma parcialmente ciega, desciega la firma y presenta el token al Verification Gate.
4. El VG valida la firma contra las claves públicas de los Implementadores aceptados, verifica el TTL y extrae la franja de edad.
5. La plataforma establece una sesión con un flag interno de franja de edad.
6. El contenido se filtra según la política de la plataforma para esa franja.
7. Al caducar el token, el DA genera uno nuevo y el VG renueva la sesión. El proceso es transparente.

6.3 Desactivación

Si el software que actúa como Device Agent se desactiva durante una sesión activa, deja de emitir tokens. En la siguiente revalidación, la sesión no puede renovarse y transiciona a un estado “no verificado”.

La política de qué hacer con sesiones no verificadas es decisión exclusiva de cada plataforma. El protocolo es deliberadamente agnóstico en este punto.

7. Modelo de Amenazas

Todo protocolo de seguridad debe analizar honestamente sus vectores de ataque:

Limitaciones reconocidas

• Dispositivos no controlados: Si un menor accede desde un dispositivo sin software que actúe como DA, AAVP no puede protegerle. El protocolo protege las puertas, no las ventanas.
• Calidad de la implementación: Una implementación deficiente del DA o del VG puede anular las garantías teóricas del protocolo.
• Complemento, no sustituto: AAVP es una herramienta técnica que complementa la educación digital y la supervisión familiar.

8. Trabajo Futuro y Líneas Abiertas

• Especificación formal: Desarrollar una especificación técnica completa en formato RFC, incluyendo formatos de mensaje, procedimientos de prueba de conformidad y test vectors.
• Implementación de referencia: Crear bibliotecas open source en múltiples lenguajes para Device Agent y Verification Gate.
• Análisis formal de seguridad: Verificación formal de las propiedades de privacidad y seguridad mediante herramientas como ProVerif o Tamarin.
• Pruebas de usabilidad: Evaluar la experiencia de usuario completa, especialmente la transparencia de la revalidación y la configuración inicial.
• Evaluación de rendimiento: Medir el impacto en latencia del handshake y optimizar para conexiones móviles de baja calidad.
• Extensibilidad del token: Explorar señales adicionales (preferencias de privacidad parentales, por ejemplo) manteniendo las garantías de anonimato.
• Gobernanza del estándar: Definir un modelo de gobernanza comunitaria para la evolución del protocolo, potencialmente bajo el W3C o el IETF.
• Migración post-cuántica: El campo token_type permite adoptar esquemas de firma ciega post-cuánticos cuando estén estandarizados. Las firmas basadas en retículos (lattice-based blind signatures) son la línea de investigación más prometedora. Los estándares NIST PQC actuales (ML-KEM, ML-DSA, SLH-DSA) no cubren firmas ciegas.
• Registro IANA: Registrar los valores de token_type y la extensión age_bracket en los registros IANA correspondientes cuando se formalice el Internet-Draft.

Glosario