Open Badge v2 vs v3 explicado: ¿qué especificación deberías usar hoy?

Si estás montando un programa de credenciales en 2026, te vas a topar con esta pregunta en la primera hora de investigación: ¿deberías emitir Open Badge v2.0 o el v3.0 más reciente? La respuesta honesta es “depende de quién tenga que leer tus credenciales” — pero eso no vale de mucho si eres tú quien tiene que decidirlo para el viernes. Así que vamos a repasar qué ha cambiado de verdad entre las dos especificaciones, quién da soporte a qué hoy en día, y cuál deberían lanzar la mayoría de emisores ahora mismo.

Qué es realmente Open Badge v2.0

Open Badge v2.0 es la especificación de 1EdTech (antes IMS Global) que ha sido la columna vertebral de las credenciales digitales desde 2017. Está construida sobre JSON-LD y estructurada en torno a tres objetos vinculados:

• IssuerOrg — quién emitió la credencial (nombre, URL, correo electrónico, logo)
• BadgeClass — el tipo de credencial en sí (nombre, descripción, criterios, imagen)
• Assertion — el otorgamiento concreto a un destinatario concreto (identidad del destinatario, fecha issuedOn, evidencia, método de verificación)

El Assertion de un destinatario apunta a un BadgeClass, que a su vez apunta a un IssuerOrg. La verificación funciona de dos maneras: hosted (el verificador obtiene el Assertion JSON en vivo desde una URL estable y confía en el dominio) o signed (el Assertion lleva una firma JWS que el verificador comprueba contra la clave pública publicada del emisor). La mayoría de plataformas, incluida badges.ninja, usan por defecto la verificación hosted con signed como opción, porque hosted es más sencilla de implementar y más fácil de comprobar a simple vista para una persona.

Aquí tienes un Assertion v2.0 recortado, del tipo que obtendrías al llamar a GET /awards/{id}:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

Esa estructura es la razón por la que v2.0 se ha convertido en el estándar de facto: es lo bastante sencilla como para implementarla en una tarde, y es lo que casi cualquier consumidor de datos de badges espera encontrarse.

Verificación hosted vs signed en v2.0

Merece la pena entender los dos modos de verificación dentro de v2.0, porque a menudo se confunde “v2.0 es menos seguro que v3.0” con “la verificación hosted es menos segura que signed”. No son el mismo eje.

• Hosted — el verification.type es "hosted", y el id del Assertion es una URL en vivo. Un verificador obtiene esa URL y comprueba que la respuesta coincide; la confianza viene de controlar el dominio (por ejemplo, solo badges.ninja puede publicar en badges.ninja/certify-badge/award/...). Esto es lo que usan la mayoría de páginas de verificación de cara al público, porque cualquiera puede simplemente pinchar en el enlace.
• Signed — el verification.type es "signed", y el Assertion lleva (o referencia) una firma JWS sobre el payload. Un verificador resuelve la clave pública del emisor y comprueba la firma sin depender de que ninguna URL esté accesible. Esto se acerca más en espíritu al modelo de v3.0, solo que sin la capa de DID.

Una comprobación mínima de verificación signed en Node se ve así:

import { jwtVerify, importJWK } from 'jose';

const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

Si a tu programa le importa que las credenciales sigan siendo verificables incluso después de que tu API se caiga por mantenimiento, v2.0 signed te da la mayor parte de la durabilidad de v3.0 sin tener que adoptar DIDs.

Qué cambia Open Badge v3.0

Open Badge v3.0 es una reescritura sobre el W3C Verifiable Credentials (VC) Data Model, no una actualización incremental de la estructura JSON-LD de v2.0. Las diferencias que importan en la práctica:

• Firma criptográfica por defecto. Cada credencial v3.0 es una VC firmada — no existe la alternativa “hosted, confía en la URL”. La verificación siempre es matemática, no basada en el dominio.
• Identidad del emisor basada en DID. En lugar de un objeto IssuerOrg con URL y correo electrónico, el emisor se identifica mediante un Identificador Descentralizado (DID), que resuelve a un documento de clave pública.
• Alineación con el Comprehensive Learner Record (CLR) 2.0. v3.0 se diseñó para interoperar con CLR, así que una sola credencial puede llevar datos del logro más el tipo de detalle de expediente estructurado que esperan los consumidores de CLR (competencias, resultados de evaluación, contexto de curso/trimestre).
• Compatibilidad con monederos digitales. Como las credenciales v3.0 son VCs estándar de W3C, se pueden guardar en monederos de identidad de la misma forma que un carnet de conducir o un certificado de vacunación — no solo mostrarse en una página web.

En resumen: v2.0 responde a “¿puede una persona o un script sencillo verificar esta credencial?”, y v3.0 responde a “¿puede esta credencial interoperar con el ecosistema más amplio de credenciales verificables — monederos, DIDs, expedientes formales de aprendizaje?“.

Comparación lado a lado

Por qué la base instalada sigue funcionando con v2.0

Esta es la parte que inclina la decisión para la mayoría de programas: los sitios donde tus destinatarios realmente quieren que aparezcan sus credenciales todavía esperan v2.0. El flujo Add to Profile de LinkedIn, Credly, Badgr y la inmensa mayoría de integraciones de sistemas de seguimiento de candidatos parsean la estructura Assertion/BadgeClass de v2.0. Si tu objetivo es que los destinatarios puedan publicar esto en LinkedIn y que los reclutadores puedan pinchar para verificarlo, v2.0 no es un formato heredado del que estés atrapado — es el formato que habla el ecosistema hoy por hoy.

Tratamos esta misma tensión desde el lado del destinatario en LinkedIn Skill Assessments vs Open Badges — el valor de un badge depende en gran medida de lo fácil que sea integrarlo en los sitios donde ya miran reclutadores y compañeros, y hoy eso es mayoritariamente infraestructura con forma de v2.0.

Cuándo v3.0 importa de verdad

v3.0 no es solo moda — resuelve problemas reales para programas concretos:

• Universidades y emisores sujetos a mandatos de CLR. Si emites junto a un sistema formal de expediente académico, o un organismo educativo estatal/regional exige salida compatible con CLR 2.0, la alineación integrada de v3.0 te evita tener que añadir campos de CLR a la fuerza sobre un Assertion v2.0.
• Programas orientados al almacenamiento en monederos digitales. Si tus destinatarios necesitan guardar la credencial en una aplicación de monedero en vez de mostrarla solo en una página web, únicamente una VC de W3C (es decir, v3.0) va a funcionar ahí de forma nativa.
• Intercambio de credenciales entre emisores con confianza basada en DID. Si estás construyendo o uniéndote a una red donde la identidad del emisor tiene que ser portable de forma criptográfica en lugar de “confía en esta URL”, los DIDs son la pieza adecuada.

Ninguno de esos son casos habituales para un programa de formación, un bootcamp o un emisor de desarrollo profesional en 2026. Son habituales en instituciones con requisitos de cumplimiento normativo o interoperabilidad que nombran explícitamente CLR o VCs de W3C.

Una credencial v3.0 recortada muestra lo distinto que es el sobre, aunque los datos del logro subyacente sean conceptualmente el mismo otorgamiento:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

Fíjate en que el campo issuer es un DID, no una URL, y en que todo el documento lleva un bloque proof en lugar de un puntero verification. Eso es la resolución de DID y las herramientas de firma de VC mencionadas antes — trabajo de ingeniería real, y trabajo que se desperdicia si todavía nadie aguas abajo lo consume.

Ideas equivocadas que conviene aclarar

• “v3.0 es más seguro.” No necesariamente — tanto v2.0 signed como v3.0 dependen de verificación criptográfica. La ventaja de v3.0 es la identidad estandarizada (DIDs) y la interoperabilidad con monederos, no una mejora de seguridad frente a v2.0 signed.
• “v2.0 está obsoleto.” No lo está. 1EdTech mantiene ambas especificaciones, y v2.0 sigue siendo la versión que referencian las plataformas e integraciones que los emisores usan en el día a día.
• “Tienes que elegir una para todo el programa.” No es así. Nada impide que un emisor publique v2.0 para uso general y añada salida v3.0 para una integración concreta con un socio que la exija — los datos del otorgamiento subyacente no cambian, solo la representación.

La ruta de migración (y por qué no hace falta elegir para siempre)

El movimiento práctico para casi cualquier emisor: saca v2.0 ahora, y trata v3.0 como una adición, no un reemplazo, cuando un consumidor concreto aguas abajo lo exija. Hay varias razones por las que esto funciona sin fricciones:

1. Los IDs de tu BadgeClass y Assertion no necesitan cambiar cuando añadas soporte para v3.0 más adelante — estás añadiendo una segunda representación, con forma distinta, del mismo otorgamiento subyacente, no migrando las credenciales de los destinatarios existentes.
2. Los verificadores que solo entienden v2.0 siguen funcionando exactamente igual que antes.
3. Evitas construir infraestructura de DID y flujos de firma de VC antes de tener un requisito concreto que los necesite.

Es la misma lógica que usamos internamente en badges.ninja: cada otorgamiento sale como un Open Badge v2.0 — JSON-LD, verificación hosted en una URL estable /certify-badge/award/{guid}, listo para Add to Profile de LinkedIn desde el primer momento — porque eso cubre la inmensa mayoría de lo que realmente se les pide a los emisores. Si tu programa necesita más adelante salida v3.0/CLR para un socio institucional concreto, eso es una adición acotada sobre un flujo v2.0 que ya funciona, no una reescritura.

Esa secuenciación también te protege de un riesgo más sutil: comprometerte con infraestructura de DID antes de saber qué método de DID esperan realmente tus socios. El ecosistema de VC todavía no ha convergido en un único método de DID — did:web, did:key y métodos anclados en ledger aparecen todos en la práctica, y elegir el equivocado para un socio piloto significa rehacer después el trabajo de identidad del emisor. Esperar a un requisito concreto con nombre propio significa que averiguas qué método necesitas de verdad antes de construir nada.

Una autoevaluación rápida para tu propio programa

Hazte estas tres preguntas antes de invertir tiempo de ingeniería en v3.0:

• ¿Algún consumidor de tus credenciales — un ATS de un empleador, un colegio profesional, una institución socia — exige explícitamente salida CLR 2.0 o VC de W3C? Si la respuesta es no, v2.0 te cubre.
• ¿Tus destinatarios necesitan guardar esta credencial en una aplicación de monedero digital, no solo en un perfil web o en LinkedIn? Si la respuesta es no, v2.0 te cubre.
• ¿Estás construyendo infraestructura de confianza entre emisores en la que la verificación hosted basada en URL realmente no es suficiente? Si la respuesta es no, v2.0 te cubre.

Si has respondido “no” las tres veces, no vas atrasado por lanzar v2.0 en 2026 — estás ajustando la especificación al ecosistema que realmente la consume. Vuelve a plantearte la pregunta cuando un socio concreto o un requisito de cumplimiento normativo pida v3.0 por su nombre, no por la sensación general de que “v3 es más nuevo”.

Para saber más sobre cómo se sostienen los datos de verificación de badges frente a formatos de credenciales antiguos y no estandarizados, echa un vistazo a Blockchain Certificates vs Open Badges, que profundiza en los compromisos de verificación y portabilidad desde otro ángulo.

---

¿Listo para emitir tu primera credencial verificable? Empieza gratis en badges.ninja — diseñador visual, página pública de verificación, certificado en PDF, salida Open Badge v2.0. No hace falta tarjeta de crédito.