¿Cómo se revoca una credencial?
Una credencial verificable, una vez emitida, vive en la wallet del ciudadano. El emisor no la controla más físicamente. Pero a veces, después de emitir, hay que invalidar la credencial: licencia suspendida, diploma anulado por fraude académico, credencial profesional retirada por mala praxis.
¿Cómo se hace esto sin pedirle al ciudadano que devuelva su credencial? La respuesta: mecanismos de revocación.
El problema en una frase
Una vez firmada criptográficamente, la credencial es válida criptográficamente para siempre. El verifier necesita un mecanismo adicional para saber si la credencial sigue vigente.
Sin revocación, el emisor solo podría emitir credenciales con vida corta y reemitirlas constantemente — caro operativamente.
Las 3 estrategias de revocación
Tres aproximaciones que coexisten en SSI moderno:
Status list
El emisor mantiene una lista pública de credenciales revocadas. El verifier consulta antes de aceptar.
Credenciales de vida corta
Las credenciales vencen rápido (días). Si hay que revocar, se deja de re-emitir. Sin mecanismo adicional.
Revocación con ZKP
Más avanzado: la credencial prueba "no estoy revocada" con ZKP, sin revelar identidad.
Para gov masivo, status list es el default. Las otras dos son complementarias para casos específicos.
BitstringStatusList — el estándar W3C
El estándar más adoptado: BitstringStatusList (W3C VC Status List 2021 + 2024).
Modelo:
- Emisor mantiene una lista de bits (típicamente 128 KB para 1M credenciales).
- Cada bit representa una credencial:
0= vigente,1= revocada. - La lista es pública, accesible por URL.
- Cuando emite una credencial, el emisor le asigna un índice (posición en la lista) y lo incluye en la credencial.
Cuando hay que revocar:
- El emisor cambia el bit del índice correspondiente de
0a1. - La lista se republica con el cambio.
Cuando un verifier verifica:
- Descarga la lista (o usa caché reciente).
- Lee el índice de la credencial.
- Si bit = 0, vigente. Si bit = 1, revocada.
La estructura en la credencial
{
"credentialSubject": {
"name": "Juan Pérez",
"license": "B1"
},
"credentialStatus": {
"id": "https://salta.gob.ar/status/list-2026#94567",
"type": "BitstringStatusListEntry",
"statusPurpose": "revocation",
"statusListIndex": "94567",
"statusListCredential": "https://salta.gob.ar/status/list-2026"
}
}
La credencial incluye un credentialStatus que apunta a la lista + el índice.
La estructura de la lista
{
"id": "https://salta.gob.ar/status/list-2026",
"type": ["VerifiableCredential", "BitstringStatusListCredential"],
"issuer": "did:web:salta.gob.ar",
"validFrom": "2026-01-01T00:00:00Z",
"credentialSubject": {
"id": "https://salta.gob.ar/status/list-2026#list",
"type": "BitstringStatusList",
"statusPurpose": "revocation",
"encodedList": "H4sIAAAAAAAAA-3BMQ0AAAACAJ..."
},
"proof": { ... }
}
La lista misma es una VerifiableCredential — firmada por el emisor, verificable por el verifier.
La compresión
128 KB para 1M credenciales suena mucho, pero con gzip + sparse data (la mayoría son 0), la lista comprime a ~10-20 KB típicamente. Y al ser cacheable + descargable infrecuentemente, el costo de red es bajo.
Ventajas y desventajas
| Aspecto | BitstringStatusList | Vida corta | ZKP-based |
|---|---|---|---|
| Privacy del holder | Verifier ve qué índice consultó | Ninguna info | Mejor |
| Carga emisor | Una lista para todos | Re-emisión constante | Compleja |
| Tiempo a revocación visible | Inmediato | Hasta vencimiento | Inmediato |
| Verificación offline | No (requiere lista) | Sí (no requiere check) | Posible |
| Estandarización | W3C BitstringStatusList | N/A | En desarrollo |
Cuándo usar cada estrategia
| Caso | Estrategia |
|---|---|
| Licencia de conducir, diplomas | BitstringStatusList |
| Constancias temporales (domicilio, certificados) | Vida corta (renovación periódica) |
| Casos con privacy crítica (votos, beneficios sociales) | ZKP-based o BitstringStatusList con cuidado |
| Identidad ciudadana base | BitstringStatusList |
El issue de privacy
BitstringStatusList tiene una limitación: cuando un verifier consulta la lista, el emisor (que la sirve) sabe que alguien está verificando la credencial índice N. No sabe quién, pero sabe cuándo.
Esto crea un canal de tracking limitado. Variantes mejoradas:
- Status List con CDN distribuido: el emisor no tiene visibilidad directa de qué índice se consulta.
- Status List bundled con la presentación: el holder envía la sección relevante de la lista junto con la credencial.
Para casos gov típicos, el tracking residual es aceptable. Para casos críticos, alternativas con ZKP son recomendables.
Implementación
// Issuer revoca una credencial
async function revokeCredential(credentialIndex: number) {
const bitstringList = await loadCurrentBitstringList();
bitstringList.setBit(credentialIndex, 1);
await publishUpdatedList(bitstringList);
}
// Verifier verifica el estado
async function checkCredentialStatus(credential: VerifiableCredential) {
const statusInfo = credential.credentialStatus;
const list = await fetchBitstringList(statusInfo.statusListCredential);
await verifyListSignature(list);
const bit = list.getBit(parseInt(statusInfo.statusListIndex));
return bit === 0 ? "vigente" : "revocada";
}
Referencias
Relacionados
- Revocar credenciales sin perder privacidad — el formato en detalle
- Credenciales de vida corta — la alternativa a revocación — estrategia complementaria
- Trust Frameworks — qué son y para qué — el contexto de confianza