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 nuevo? La respuesta honesta es “depende de quién tenga que leer tus credenciales” — pero eso no ayuda mucho si eres tú quien tiene que decidir antes del viernes. Así que repasemos qué cambió realmente entre las dos especificaciones, quién soporta 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, email, logo)
• BadgeClass — el tipo de credencial en sí (nombre, descripción, criterios, imagen)
• Assertion — el otorgamiento específico a un destinatario específico (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 formas: 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 simple 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 simple como para implementarla en una tarde, y es lo que casi cualquier consumidor de datos de badges espera ver.

Verificación hosted vs signed en v2.0

Vale la pena entender los dos modos de verificación dentro de v2.0, porque la gente suele confundir “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 una persona simplemente puede hacer clic 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 tu programa necesita que las credenciales sigan siendo verificables incluso después de que tu API esté fuera de servicio por mantenimiento, v2.0 signed te da la mayor parte del beneficio de durabilidad de v3.0 sin 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 hay alternativa “hosted, confía en la URL”. La verificación siempre es matemática, no basada en dominio.
• Identidad del emisor basada en DID. En lugar de un objeto IssuerOrg con URL y email, 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 fue diseñado 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/término).
• Compatibilidad con billeteras digitales. Como las credenciales v3.0 son VCs estándar de W3C, pueden guardarse en billeteras de identidad de la misma forma que una licencia 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 simple verificar esta credencial?”, y v3.0 responde a “¿puede esta credencial interoperar con el ecosistema más amplio de credenciales verificables — billeteras, 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 lugares 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 gran 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 hacer clic para verificarlo”, v2.0 no es un formato legado del que estés atrapado — es el formato que habla el ecosistema actualmente.

Cubrimos 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 qué tan fácil se integra en los lugares donde ya miran reclutadores y colegas, y hoy eso es abrumadoramente infraestructura con forma de v2.0.

Cuándo v3.0 realmente importa

v3.0 no es hype — resuelve problemas reales para programas específicos:

• Universidades y emisores bajo mandatos de CLR. Si estás emitiendo 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 ahorra tener que añadir campos de CLR a un Assertion v2.0 a la fuerza.
• Programas orientados a almacenamiento en billeteras digitales. Si tus destinatarios necesitan guardar la credencial en una app de billetera en lugar de solo mostrarla en una página web, solo una VC de W3C (es decir, v3.0) va a funcionar de forma nativa ahí.
• 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 necesita ser portable criptográficamente en lugar de “confía en esta URL”, los DIDs son la primitiva correcta.

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

Una credencial v3.0 recortada muestra lo distinto que se ve 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 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 río abajo lo consume.

Ideas equivocadas que vale la pena aclarar

• “v3.0 es más seguro.” No necesariamente — v2.0 signed y v3.0 dependen ambos de verificación criptográfica. La ventaja de v3.0 es la identidad estandarizada (DIDs) y la interoperabilidad con billeteras, no una mejora de seguridad sobre 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 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 específica con un socio que la requiera — los datos del otorgamiento subyacente no cambian, solo la representación.

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

El movimiento práctico para casi cualquier emisor: lanza v2.0 ahora, y trata v3.0 como una adición, no un reemplazo, cuando un consumidor específico río 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 agregues 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 pipelines de firma de VC antes de tener un requisito concreto que los necesite.

Esta 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 abrumadora mayoría de lo que realmente se les pide a los emisores. Si tu programa necesita después salida v3.0/CLR para un socio institucional específico, eso es una adición acotada sobre un pipeline v2.0 que ya funciona, no una reescritura.

Esa secuencia 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 significa que descubres qué método necesitas realmente 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 organismo de licencias, una institución socia — exige explícitamente salida CLR 2.0 o VC de W3C? Si no, v2.0 te cubre.
• ¿Tus destinatarios necesitan guardar esta credencial en una app de billetera digital, no solo en un perfil web o en LinkedIn? Si no, v2.0 te cubre.
• ¿Estás construyendo infraestructura de confianza entre emisores donde la verificación hosted basada en URL genuinamente no es suficiente? Si no, v2.0 te cubre.

Si respondiste “no” tres veces, no vas atrasado por lanzar v2.0 en 2026 — estás ajustando la especificación al ecosistema que realmente la consume. Revisa la pregunta cuando un socio específico o un requisito de cumplimiento pida v3.0 por nombre, no basado en la sensación general de que “v3 es más nuevo”.

Para más sobre cómo se sostienen los datos de verificación de badges frente a formatos de credenciales antiguos y no estándar, mira 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 se necesita tarjeta de crédito.