Revocar credenciales sin perder privacidad

Una credencial verificable puede tener que ser revocada antes de su fecha de vencimiento: el ciudadano perdió un puesto, la matrícula caducó, la información fue corregida, hubo un error de emisión. El verificador necesita saberlo, pero el mecanismo de revocación tiene que respetar dos propiedades fundamentales del modelo SSI: el verificador no contacta al emisor, y el emisor no sabe quién está verificando.

El estándar canónico del W3C para resolver este problema se llama BitstringStatusList. Es elegante, escalable y preserva la privacidad por diseño.

El problema que resuelve

Los dos extremos a evitar son obvios:

BitstringStatusList resuelve ambos: el emisor publica un único bitstring grande que se descarga una vez y se cachea. Cada credencial sabe en qué bit de ese bitstring vive su status. El verificador chequea ese bit localmente.

Cómo funciona

1. 1
   El emisor mantiene un bitstring de N bits (típicamente 131.072 bits = 16 KB sin comprimir). Cada bit representa una credencial.
2. 2
   Al emitir, el emisor le asigna un statusListIndex a la credencial: "tu status vive en el bit 94.567".
3. 3
   La credencial lleva esa referencia en su campo credentialStatus.
4. 4
   El bitstring completo se publica en una URL pública (https://issuer.gob/credentials/status/3), firmado como una VC más.
5. 5
   Cuando alguien revoca, el emisor flippea el bit correspondiente y republica.
6. 6
   Para verificar: descargar el bitstring, leer el bit que indica statusListIndex. Listo.

El bitstring se descarga una vez por verificador y se cachea. El emisor no se entera quién consulta el status de qué credencial: solo ve descargas del bitstring entero.

Privacidad por diseño

Estructura de los datos

En cada credencial emitida, se incluye una referencia al status list:

"credentialStatus": {
  "id": "https://salta.gob.ar/credentials/status/3#94567",
  "type": "BitstringStatusListEntry",
  "statusPurpose": "revocation",
  "statusListIndex": "94567",
  "statusListCredential": "https://salta.gob.ar/credentials/status/3"
}

El status list mismo es una credencial verificable:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "https://salta.gob.ar/credentials/status/3",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:web:salta.gob.ar",
  "validFrom": "2026-05-17T00:00:00Z",
  "credentialSubject": {
    "id": "https://salta.gob.ar/credentials/status/3#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "uH4sIAAAAAAAA_..."
  }
}

El campo encodedList es el bitstring comprimido con GZIP y codificado en base64url. Estar firmado como una VC es importante: garantiza que solo el emisor real puede publicar listas autorizadas. Si alguien intentara servir una lista falsa, la firma no validaría.

Operación de revocación

import { loadStatusList, flipBit, signVC } from "@sovrahq/agent";

async function revoke(credentialId: string) {
  const credential = await db.credentials.get(credentialId);
  const listId = credential.statusListCredential;
  const index = credential.statusListIndex;

  // Cargar el bitstring actual, flippear el bit, re-firmar
  const list = await loadStatusList(listId);
  flipBit(list, index, 1);

  const signed = await signVC(list, {
    issuer: "did:web:salta.gob.ar",
  });

  await statusListStore.publish(listId, signed);
}

Republicar es atómico: una versión cacheada vieja sigue funcionando hasta que el TTL expira, momento en que los verificadores descargan la nueva.

Verificación de status

import { resolveStatusList, getBit } from "@sovrahq/agent";

async function isRevoked(credential: VerifiableCredential): Promise<boolean> {
  const statusEntry = credential.credentialStatus;
  if (!statusEntry) return false;

  // Resolver y verificar firma del status list
  const list = await resolveStatusList(statusEntry.statusListCredential);

  // Leer el bit del índice de esta credencial
  const bit = getBit(list.encodedList, Number(statusEntry.statusListIndex));

  return bit === 1;
}

El verificador cachea las status lists típicamente por 5-60 minutos según el caso de uso. Para credenciales críticas (financiero, salud), TTL más corto. Para casos de baja sensibilidad, TTL más largo.

Tamaños y ritmo de revocación

Una jurisdicción que emite millones de credenciales mantiene varias listas. Cada credencial lleva el índice + la URL específica de su lista. No hay límite práctico a la escala.

Más allá de "revocada / vigente"

El campo statusPurpose no se limita a revocación. Soporta otros estados:

Para casos avanzados se pueden combinar listas: una para revocación, otra para suspensión, ambas referenciadas desde la misma credencial.

Alternativas (cuándo no usar BitstringStatusList)

Migración desde StatusList2021

Si tu sistema ya emite credenciales con StatusList2021 (el predecesor en el W3C VC 1.1), la migración es directa: la estructura es casi idéntica, los conceptos son los mismos. Las diferencias clave:

• type pasa de StatusList2021Credential a BitstringStatusListCredential.
• RevocationList2020Status y RevocationList2021Status se unifican en BitstringStatusListEntry.
• El statusPurpose ahora es obligatorio y declara explícitamente la semántica del bit.

Las credenciales viejas con StatusList2021 siguen siendo válidas. Los emisores migran al nuevo formato a medida que emiten credenciales nuevas.

Referencias

• W3C BitstringStatusList Recommendation
• W3C VC Data Model 2.0 — credentialStatus

Relacionados

• W3C Verifiable Credentials Data Model 2.0 — donde vive el campo credentialStatus
• Cómo emite credenciales un sistema con OID4VCI — emisión asigna el statusListIndex
• ¿Qué es una credencial verificable? — la base conceptual