Qué prueba realmente un recibo de consentimiento firmado

Publicado el 16 de septiembre de 2026

La mayoría de las herramientas de consentimiento guardan una fila en su propia base de datos. Un justificante firmado con Ed25519 es un documento pequeño que cualquiera puede verificar después, incluso sin conexión y sin tener que confiar en nosotros.

Cuando un regulador revisa el cumplimiento de RGPD, no pregunta solo "¿registraste el consentimiento?". Pregunta si el rastro de auditoría sigue intacto años después, si se puede reconstruir exactamente qué vio la persona y cuándo, y si esa prueba aguanta el escrutinio sin depender de que alguien más la confirme de palabra.

Ahí es donde la mayoría de las plataformas de consentimiento se quedan cortas: producen un registro dentro de su propio sistema. Sirve mientras el proveedor exista, coopere y su base de datos no cambie. Un justificante firmado no depende de nada de eso.

El problema de una prueba que solo tú controlas

Una fila en una base de datos vale lo que valga la confianza en quien la controla. Si dentro de tres años un usuario disputa haber dado su consentimiento, o un auditor pide evidencia de un evento concreto, la respuesta habitual es "consúltalo en nuestro panel". Eso obliga al regulador, o a la otra parte, a confiar en el proveedor, o directamente a pedirle acceso a sus sistemas internos.

Un justificante cambia esa relación. Es un documento pequeño y autónomo: "en esta fecha, esta persona aceptó exactamente este texto", con una firma criptográfica que cualquiera puede comprobar por su cuenta. No hace falta llamar a nuestra API. No hace falta creer nada de lo que digamos.

Qué contiene, exactamente

Cada respuesta de POST /v1/consent incluye un receiptId. El justificante completo tiene esta forma:

GET /v1/receipts/rcpt_9f2c…

{
  "receiptId": "rcpt_9f2c…",
  "issuedAt": "2024-05-01T10:03:00Z",
  "payload": {
    "subject": "<hash del identificador>",
    "purpose": "marketing_email",
    "version": 1,
    "statementHash": "<hash del texto exacto mostrado>",
    "state": "GRANTED",
    "controller": "Acme Ltd"
  },
  "algorithm": "EdDSA",
  "kid": "key_2024a",
  "signature": "<base64url>"
}

Nota lo que no lleva: el payload no contiene datos personales en claro. El sujeto y el texto exacto de la cláusula van con hash, así que el justificante se puede entregar a un tercero (un auditor, un DPA, la otra parte de un contrato) sin exponer nada más que lo estrictamente necesario para verificarlo.

Cómo lo verifica cualquiera, sin llamarnos

La firma es Ed25519 estándar. No hace falta nuestro SDK ni nuestra cooperación, solo una biblioteca de criptografía y cuatro pasos:

1. Descargar las claves públicas de GET /.well-known/jwks.json.
2. Elegir la clave cuyo kid coincide con el del justificante.
3. Reserializar el payload con las claves del objeto ordenadas (JSON Canonicalization, RFC 8785).
4. Verificar signature sobre esos bytes con la clave pública Ed25519.

Para quien no quiera implementar esos cuatro pasos: await tc.verifyReceipt(receipt) en el SDK de JavaScript los hace con la Web Crypto del navegador, o GET /v1/receipts/{id}/verify los repite en nuestro servidor y devuelve { valid: true }. Pero la garantía real es otra: no hace falta ninguna de las dos opciones, porque el criptosistema es público y estándar.

Por qué una clave antigua nunca se retira

Rotamos las claves de firma con el tiempo, como cualquier sistema serio. La diferencia es que nunca retiramos una clave pública antigua: un justificante emitido hoy seguirá verificándose dentro de diez años, con la misma clave publicada en el mismo /.well-known/jwks.json. Un registro que vive solo en una base de datos no tiene esa garantía. Simplemente confías en que la fila sigue ahí y no ha cambiado.

Lo que esto significa el día de una auditoría real

Cuando llega ese día, la diferencia práctica es esta: en lugar de dar acceso a tu panel o pedirle a un proveedor que confirme algo por escrito, entregas un archivo. El auditor lo verifica con sus propias herramientas, en su propio equipo, sin depender de que nadie responda a tiempo. Eso es lo que separa una prueba de un simple registro.

La referencia técnica completa está en la documentación de justificantes, con el esquema exacto del payload y los casos límite de la verificación. Si quieres verlo funcionando, la guía de puesta en marcha tarda menos de diez minutos.