Las credenciales verificables están llegando a cada vez más ámbitos: licencias de conducir en billeteras digitales, títulos universitarios, matrículas profesionales y comprobaciones de edad. Muchas soluciones destacan una misma propiedad: la credencial tiene una firma digital que permite comprobar que su contenido no fue alterado.
Es una propiedad fundamental, pero no resuelve todo lo que necesita saber quien recibe una credencial.
Un verificador también tiene que saber quién controla la clave que firmó el documento, si esa entidad estaba autorizada para emitirlo y si la credencial sigue vigente. Para responder esas preguntas necesita consultar información que está fuera de la propia credencial: la clave pública del emisor, que se obtiene a partir de su identificador descentralizado (DID), el registro de emisores de confianza y la lista de estado de la credencial.
Ahí aparece una pregunta de diseño tan importante como la firma: dónde viven esos registros, quién los controla y quién puede consultarlos.
Un sistema puede emitir credenciales que cumplen con los estándares y verificarlas dentro de su propia plataforma. Eso no significa necesariamente que cualquier institución pueda hacer las mismas comprobaciones por su cuenta, sin depender de quien la opera.
Verificar fuera de la plataforma que emitió
El Verifiable Credentials Data Model 2.0 del W3C define cómo representar y verificar credenciales digitales. Cumplir con ese estándar es la base, y aun así no garantiza por sí solo que distintas instituciones puedan verificar credenciales de forma independiente.
En muchos sistemas, las claves de los emisores y las listas de estado se publican en servidores administrados por el emisor o por la plataforma. Con did:web, por ejemplo, las claves son un archivo en el dominio del emisor, y la Bitstring Status List se descarga desde la dirección que indica cada credencial. Cualquiera puede consultarlos por internet, y el modelo funciona. La verificación, en cambio, queda atada a la disponibilidad de esos servidores, a quien los controla y a lo que muestren en el momento de la consulta: un documento did:web refleja las claves actuales, y el historial de cambios depende de que el emisor lo conserve.
Cuando una credencial sale de su ecosistema original, otro verificador puede necesitar consultar servicios específicos o integrarse con la misma plataforma. La credencial es verificable dentro de ese sistema, y fuera de él hace falta una infraestructura compartida para comprobarla.
Qué cambia con un registro público
Una alternativa es mantener los registros necesarios para la verificación en una infraestructura pública y auditable. El propio modelo de datos del W3C espera que ese registro sea a prueba de alteraciones y menciona una blockchain entre las formas de lograrlo.
Esto permite que distintos verificadores consulten una fuente común para comprobar las claves de los emisores, sus autorizaciones y el estado de las credenciales. Cada rotación de clave y cada cambio de estado queda registrado en orden, así que una firma de 2021 se comprueba contra la clave que el emisor usaba en 2021, y cualquier verificación pasada se puede auditar. Como el verificador lee el registro público, la verificación sigue funcionando aunque el servidor del emisor esté caído.
La gobernanza sigue siendo necesaria: alguien debe definir quién puede emitir cada tipo de credencial y bajo qué condiciones. Lo que cambia es cómo se registran esas decisiones y cómo terceros pueden comprobarlas. Explicamos ese lado en los tres registros de Propia.
La privacidad también importa. Los registros contienen claves públicas, autorizaciones y estados, sin publicar las credenciales ni los datos personales de sus titulares. Cada lista de estado cubre al menos 131.072 credenciales, así que consultarla no revela cuál se está verificando.
Cómo lo hacemos en Sovra
SovraChain es una Layer 2 de Ethereum que funciona en modo validium. Corre sobre Ethrex, el cliente de ejecución desarrollado por LambdaClass, y ya acumula más de 10 millones de anclajes.
En ella registramos los documentos DID de los emisores y su historial de operaciones, el registro de emisores de confianza, las listas de estado y los esquemas de credenciales.
Utilizamos did, compatible con W3C DID Core, y Bitstring Status List v1.0 para publicar el estado de las credenciales mediante un mecanismo estandarizado.
Los componentes trabajan en conjunto:
SovraID permite a las instituciones emitir y verificar credenciales.
SovraWallet permite a las personas guardar y presentar sus credenciales desde el teléfono.
SovraChain mantiene los registros compartidos que respaldan la verificación.
Las credenciales y los datos personales no se publican en la cadena.
El objetivo es que la verificación no dependa exclusivamente de la plataforma que emitió una credencial. Las instituciones pueden apoyarse en estándares abiertos y registros compartidos para comprobar la información necesaria, de acuerdo con las reglas de confianza aplicables.
Podés ver en vivo cómo se emite y se verifica una credencial.
Qué preguntar al evaluar una solución
Antes de elegir una plataforma de credenciales verificables, conviene preguntar:
¿Puede una institución independiente verificar las credenciales sin depender del proveedor?
¿Dónde se publican las claves y las listas de estado?
¿Existe un historial auditable de los cambios de claves y de estado?
¿Cómo se determina qué emisores son confiables?
¿Qué información se publica y cuál permanece privada?
Una firma válida es indispensable, y la interoperabilidad depende también de la infraestructura que permite comprobarla y compartir la confianza entre instituciones.
Para profundizar
Verifiable Credentials Data Model 2.0 (W3C): el estándar que define qué es una credencial verificable y cómo se verifica.
Bitstring Status List v1.0 (W3C): el mecanismo estándar para publicar si una credencial fue revocada o suspendida.
The full lifecycle of a verifiable credential: emisión, guardado y verificación, paso a paso.
How a Country Verifies an Identity Issued by Another: qué comprueba un gobierno antes de aceptar una credencial emitida en otro país.
Sigamos la conversación
En nuestro centro de conocimiento, sovra.io/knowledge, explicamos DID, credenciales verificables y listas de estado en lenguaje simple.
¿Qué otra pregunta le harías a una plataforma de credenciales antes de elegirla? Respondé este correo y contanos: leemos todas las respuestas. Si alguien de tu equipo está evaluando soluciones de identidad, reenviale esta edición.
Suscribite a The Identity Brief, que se publica todas las semanas.