Open Badges: el estándar abierto tras las credenciales verificables

El estándar divide una credencial en tres partes, y la separación es más ingeniosa de lo que parece al principio. El Issuer describe quién emite: nombre, web, contacto. La BadgeClass describe qué se otorga: título de la credencial, descripción, criterios, imagen. La Assertion, por último, es cada entrega concreta: esta persona recibió esta BadgeClass en esta fecha.

Así, la descripción de un tipo de certificado solo tiene que existir una vez, tanto si lo otorgáis a 20 personas como a 2.000. Este es el aspecto de una Assertion real de nuestro sistema, con el token acortado:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

Dos detalles merecen una segunda mirada. El campo badge es solo una dirección: allí está la BadgeClass, que a su vez apunta al Issuer, y así una herramienta de verificación recorre toda la cadena. Y como recipient figura aquí la dirección de la página del certificado; una dirección de correo, incluso una con hash, no aparece por ninguna parte. El documento público prescinde así de cualquier dato de contacto directo. El nombre de la persona está en la página del certificado enlazada, donde ella misma lo escribió al canjearlo.

La especificación conoce dos caminos para hacer verificable una Assertion. En los badges firmados, el documento lleva una firma criptográfica del emisor, con lo que se demuestra a sí mismo, pero para ello necesita una gestión de claves por parte del emisor. En los badges alojados rige una regla más sencilla: la Assertion es auténtica mientras se pueda recuperar en su propia dirección id desde el emisor. Verificar significa entonces solo esto: solicitar la URL y comparar.

El procedimiento alojado tiene una ventaja infravalorada: la revocación limpia. Cuando el emisor retira una credencial, la misma dirección responde a partir de ese momento con el estado HTTP 410 y un documento breve con la línea «revoked: true». Un certificado retirado no desaparece sin más: sigue respondiendo de forma activa para señalar que ya no es válido. Así lo hacemos también en OneClickBadge, por ejemplo cuando un certificado se emitió dos veces por error.

Un detalle del estándar es casi poético: el «baking». La imagen del badge, casi siempre un PNG, recibe su Assertion junto con la dirección de verificación incrustada directamente en el archivo de imagen, técnicamente como un bloque de texto iTXt con la palabra clave openbadges. La imagen tiene después exactamente el mismo aspecto, pero lleva su ruta de verificación dentro de sí: quien arrastra el archivo a una herramienta de verificación acaba en la Assertion, por muchas descargas y chats por los que haya pasado la imagen.

El orden de prioridad sigue importando: demostrar algo solo puede hacerlo la Assertion alojada. Una imagen se puede copiar y modificar a voluntad, mientras que la respuesta en la dirección de la credencial la controla únicamente el emisor.

Aquí despejamos el malentendido más común que ronda por muchos artículos: LinkedIn no lee los metadatos de un Open Badge. Allí no hay importación de badges, ni verificación automática, ni un icono especial para badges verificados. Lo que LinkedIn tiene es la sección del perfil «Licencias y certificaciones», con campos para un nombre, la organización emisora y una URL. Nada de eso significa que LinkedIn certifique o avale nada.

Aun así, el estándar no resulta inútil para LinkedIn, al contrario: en el campo de la URL va la dirección de la credencial. Quien pulsa «Mostrar credencial» en el perfil llega a la página del certificado, tras la cual está la Assertion verificable. La propia entrada se puede preparar para los destinatarios con un solo clic, con los campos del formulario ya rellenados. Cómo se ve esto desde el lado de los asistentes lo muestra la guía para añadirlo al perfil.

Implementar el estándar por cuenta propia le compensa a muy pocos organizadores: necesitaríais endpoints accesibles de forma permanente para el Issuer, la BadgeClass y cada Assertion individual, además de la lógica de revocación y una imagen con el baking hecho. Para eventos, webinars y formaciones existe una vía ya lista: en OneClickBadge diseñáis un certificado de asistencia, y cada ejemplar emitido recibe de forma automática su Assertion alojada, el mecanismo de revocación y el PDF con la imagen.

El reparto a muchos asistentes se hace sin subir ninguna lista, a través de un enlace de autoservicio que compartís después del evento. Por qué esto, precisamente en el terreno de las credenciales, es también una decisión de protección de datos lo explica la página Certificados para muchos asistentes.

La versión 3.0 traslada el estándar a las Verifiable Credentials del W3C, un modelo con firmas criptográficas y más control en manos del destinatario. Para los ecosistemas universitarios y los títulos formativos de larga vida, esa es la dirección correcta. Para el caso de uso de la asistencia a eventos, la 2.0 en su forma alojada es hoy el estado pragmático: cualquier herramienta de verificación habitual la entiende, la revocación funciona y nadie tiene que gestionar carteras ni claves. Por eso apostamos por la 2.0 alojada y seguimos observando la 3.0 con calma.