Consent management — el consentimiento como datos
El consentimiento del ciudadano es uno de los pilares de la protección de datos personales bajo LPDP y GDPR. En sistemas SSI, el consentimiento es más granular y operativamente complejo que en sistemas centralizados — pero también puede ser más respetuoso de privacy si se implementa bien.
Este artículo cubre cómo gestionar consentimiento en SSI gov.
El espectro del consentimiento
En sistemas SSI, el ciudadano da consentimiento en varios momentos:
- 1Al recibir una credencial. "¿Acepta que el organismo X le emita esta credencial?"
- 2Al guardar la credencial en wallet. Confirmación de almacenamiento.
- 3Al presentar la credencial a un verifier. "¿Confirma compartir estos atributos con Z?"
- 4Al actualizar política de privacy. Cuando el operador cambia algo, consentimiento nuevo.
Cada uno requiere consentimiento explícito y trazable.
Los principios del consentimiento bajo LPDP
LPDP define el consentimiento como:
- Libre. No coercitivo. El ciudadano puede negarse sin consecuencias indebidas.
- Específico. Para un propósito determinado. No "consentimiento general".
- Informado. El ciudadano sabe qué consiente.
- Expreso. Acción afirmativa, no silencio o continuación.
- Revocable. El ciudadano puede retirar el consentimiento.
Estos principios deben implementarse en el flujo del sistema, no en políticas escritas.
El modelo de consentimiento en SSI
En la práctica, una wallet SSI debe:
| Etapa | UX |
|---|---|
| Al recibir credencial | Mostrar exactamente qué se va a emitir, por quién, para qué |
| Al presentar credencial | Mostrar al verifier + qué atributos se van a revelar |
| Confirmación | Acción explícita ("Aceptar", swipe, biométrica) |
| Revocación | Acceso desde la wallet para retirar credenciales o consentimientos |
Cada acción consiste en datos guardados (consentimiento trazable + revocable).
La estructura técnica del consentimiento
Un evento de consentimiento se modela como:
{
"id": "consent-12345",
"type": "ConsentEvent",
"subject": "did:key:z6Mk...",
"to": "did:web:salta.gob.ar",
"purpose": "Recibir credencial Constancia de Domicilio",
"scope": ["constancia-domicilio"],
"expiresAt": "2026-06-18T00:00:00Z",
"createdAt": "2026-05-18T10:30:00Z",
"signature": "...",
"revocable": true
}
El consentimiento mismo es una credencial firmada por el ciudadano que registra la autorización.
La revocación del consentimiento
Cuando el ciudadano retira el consentimiento:
- 1Notificación al operador. El ciudadano marca "retirar consentimiento" en la wallet.
- 2Acknowledgment. El operador confirma recepción.
- 3Action consecuencial. Las credenciales asociadas se revocan o se marcan para no usar.
- 4Logging. El evento de revocación queda registrado en el audit trail.
- 5Compliance. El operador cumple con los procesos LPDP de cancelación.
El consent fatigue
Un problema operativo: si el sistema pide consentimiento en cada paso, el ciudadano se fatigue y deja de leer.
Patrones de mitigación:
- Consentimiento agrupado cuando los pasos están relacionados.
- Consentimiento por defecto para acciones rutinarias previamente autorizadas.
- Notificaciones agregadas en lugar de pop-ups individuales.
- Configurable defaults que el ciudadano puede ajustar.
Sin estos, el consentimiento se vuelve UI noise que pierde valor protector.
El consent por defecto
Una decisión política: ¿qué es lo predeterminado?
| Opt-in | Opt-out | |
|---|---|---|
| Default | Ningún consentimiento sin acción | Consentimiento asumido |
| Privacy | Más protectiva | Menos protectiva |
| Adopción | Menor (más fricción) | Mayor (menos fricción) |
| LPDP compliant | Sí | Cuestionable |
| eIDAS / GDPR compliant | Sí | NO |
Para casos gov, opt-in es el default correcto. Especialmente para uso de datos más allá del propósito inmediato.
El consentimiento dinámico
Más allá del consentimiento inicial, el ciudadano puede ajustar dinámicamente:
- Mostrar o ocultar credenciales específicas del verifier.
- Configurar atributos a revelar por credencial.
- Establecer reglas de auto-presentación ("siempre comparto con el banco X").
- Revocar credenciales sin afectar otras.
Una buena wallet ofrece todas estas opciones desde el centro de configuración.
El audit del consentimiento
El sistema debe trackear:
| Evento | Logged |
|---|---|
| Otorgamiento de consentimiento | Sí (con timestamp + scope) |
| Revocación | Sí (con razón si está disponible) |
| Cambio de configuración | Sí (qué cambió, cuándo) |
Estos logs son operativos del ciudadano, no del operador. Son parte de los derechos ARCO del ciudadano: él puede consultar su historial de consentimientos otorgados.
El stack técnico
Implementación robusta de consent management:
- Wallet stores consents: la wallet del ciudadano es source of truth para sus consentimientos.
- Operator logs verificable: el operador mantiene logs verificables que pueden contrastarse con la wallet.
- Sync on revocation: cuando hay revocación, ambos sistemas se sincronizan.
- Audit visibility: el ciudadano puede ver, desde su wallet, qué consentimientos ha otorgado.
El caso ideal: el panel de consents
Una wallet seria muestra al ciudadano:
Tus credenciales:
- Constancia Domicilio (Gob Salta) - Recibida 15/03/2026
Consentimientos otorgados: 3
- Banco Galicia (vencido)
- Servicio de luz (activo, expira 18/05/2026)
- Trámite escolar (activo, sin expiración)
→ Revocar consentimientos individuales
Esto es transparencia real. El ciudadano sabe quién tiene acceso a qué credencial, hasta cuándo.
Referencias
Relacionados
- LPDP 25.326 — qué pide a la identidad digital — marco regulatorio
- Audit trail y compliance — trazabilidad sin tracking — la auditoría operativa
- Credenciales vs tokens — la distinción clave — distinción técnica relevante