Open Badge v2 vs v3 explicat: quina especificació hauries d'utilitzar avui?

Si estàs configurant un programa de credencials el 2026, et trobaràs amb aquesta pregunta durant la primera hora de la teva recerca: hauries d’emetre Open Badge v2.0 o el més nou v3.0? La resposta honesta és “depèn de qui hagi de llegir les teves credencials” — però això no és satisfactori si ets tu qui ha de decidir-ho abans de divendres. Així que anem a repassar què ha canviat realment entre les dues especificacions, qui suporta què avui, i quina haurien de fer servir la majoria d’emissors ara mateix.

Què és realment Open Badge v2.0

Open Badge v2.0 és l’especificació d’1EdTech (abans IMS Global) que ha estat l’espina dorsal de l’emissió de credencials digitals des del 2017. Està construïda sobre JSON-LD i estructurada al voltant de tres objectes enllaçats:

• IssuerOrg — qui va emetre la insígnia (nom, URL, correu electrònic, logotip)
• BadgeClass — el tipus de credencial en si mateix (nom, descripció, criteris, imatge)
• Assertion — l’atorgament específic a un destinatari específic (identitat del destinatari, data issuedOn, evidència, mètode de verificació)

L’Assertion d’un destinatari apunta a un BadgeClass, que al seu torn apunta a un IssuerOrg. La verificació es fa d’una de dues maneres: hosted (el verificador recupera el JSON de l’Assertion en viu des d’una URL estable i confia en el domini) o signed (l’Assertion porta una signatura JWS que el verificador comprova contra la clau pública publicada per l’emissor). La majoria de plataformes, incloent-hi badges.ninja, fan servir per defecte la verificació hosted amb signed com a opció, perquè hosted és més senzilla d’implementar i més fàcil de comprovar manualment per a una persona.

Aquí tens una Assertion v2.0 retallada, el tipus de resposta que obtindries d’una crida 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" }
}

Aquesta estructura és la raó per la qual v2.0 s’ha convertit en l’estàndard de facto: és prou senzilla per implementar-la en una tarda, i és el que gairebé tots els consumidors de dades de credencials esperen veure.

Verificació hosted vs signed a v2.0

Val la pena entendre els dos modes de verificació dins del mateix v2.0, perquè sovint la gent confon “v2.0 és menys segur que v3.0” amb “la verificació hosted és menys segura que la signed”. No són el mateix eix.

• Hosted — el verification.type és "hosted", i l’id de l’Assertion és una URL en viu. Un verificador recupera aquesta URL i comprova que la resposta coincideixi; la confiança prové de controlar el domini (per exemple, només badges.ninja pot publicar a badges.ninja/certify-badge/award/...). Això és el que fan servir la majoria de pàgines de verificació orientades a l’usuari final, perquè una persona pot simplement clicar l’enllaç.
• Signed — el verification.type és "signed", i l’Assertion porta (o referencia) una signatura JWS sobre el contingut. Un verificador resol la clau pública de l’emissor i comprova la signatura independentment de si alguna URL és accessible. Això s’assembla més en esperit al model de v3.0, només que sense la capa DID.

Una comprovació mínima de verificació signed a Node es veu així:

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 al teu programa li importa que les credencials segueixin sent verificables fins i tot després que la teva API estigui fora de línia per manteniment, signed v2.0 t’aporta la majoria dels avantatges de durabilitat de v3.0 sense haver d’adoptar DID.

Què canvia Open Badge v3.0

Open Badge v3.0 és una reescriptura sobre el W3C Verifiable Credentials (VC) Data Model, no una actualització incremental de la forma JSON-LD de v2.0. Les diferències que importen a la pràctica:

• Signatura criptogràfica per defecte. Cada credencial v3.0 és una VC signed — no hi ha alternativa “hosted, confia en la URL”. La verificació és sempre matemàtica, no basada en el domini.
• Identitat de l’emissor basada en DID. En lloc d’un objecte IssuerOrg amb una URL i un correu electrònic, l’emissor s’identifica amb un Identificador Descentralitzat (DID), que es resol a un document de clau pública.
• Alineació amb el Comprehensive Learner Record (CLR) 2.0. v3.0 va ser dissenyat per interoperar amb CLR, de manera que una sola credencial pot portar dades d’assoliment més el tipus de detall d’expedient estructurat que els consumidors de CLR esperen (competències, resultats d’avaluació, context de trimestre/curs).
• Compatibilitat amb carteres digitals. Com que les credencials v3.0 són VC estàndard del W3C, es poden guardar en carteres d’identitat de la mateixa manera que un carnet de conduir o un certificat de vacunació — no només mostrar-se en una pàgina web.

En resum: v2.0 respon “pot una persona o un script senzill verificar aquesta credencial”, i v3.0 respon “pot aquesta credencial interoperar amb l’ecosistema més ampli de verifiable credentials — carteres, DID, expedients acadèmics formals”.

Comparació costat a costat

Per què la base instal·lada encara funciona amb v2.0

Aquesta és la part que decanta la decisió per a la majoria de programes: els llocs on els teus destinataris realment volen que aparegin les seves credencials encara esperen v2.0. El flux Add to Profile de LinkedIn, Credly, Badgr, i la gran majoria d’integracions de sistemes de seguiment de candidats analitzen la forma Assertion/BadgeClass de v2.0. Si el teu objectiu és “els destinataris poden publicar això a LinkedIn i els reclutadors poden clicar per verificar-ho”, v2.0 no és un format obsolet en què estiguis atrapat — és el format que parla l’ecosistema actualment.

Vam tractar aquesta mateixa tensió des del punt de vista del destinatari a LinkedIn Skill Assessments vs Open Badges — el valor d’una insígnia és en gran part una funció de com d’fàcilment encaixa en els llocs on els reclutadors i companys ja miren, i avui això és majoritàriament infraestructura amb forma v2.0.

Quan v3.0 realment importa

v3.0 no és bombo — resol problemes reals per a programes específics:

• Universitats i emissors sota mandats de CLR. Si emets al costat d’un sistema d’expedient formal, o un organisme educatiu estatal/regional requereix una sortida compatible amb CLR 2.0, l’alineació integrada de v3.0 t’estalvia haver d’afegir camps de CLR a una Assertion v2.0.
• Programes orientats a l’emmagatzematge en cartera digital. Si els teus destinataris necessiten guardar la credencial en una aplicació de cartera en lloc de només mostrar-la en una pàgina web, només una VC del W3C (és a dir, v3.0) funcionarà de manera nativa allà.
• Intercanvi de credencials entre emissors amb confiança basada en DID. Si estàs construint o unint-te a una xarxa on la identitat de l’emissor ha de ser portable criptogràficament en lloc de “confia en aquesta URL”, els DID són la primitiva adequada.

Cap d’aquests són casos habituals per a un programa de formació, un bootcamp o un emissor de desenvolupament professional el 2026. Són habituals per a institucions amb requisits de compliment o interoperabilitat que anomenen específicament CLR o VC del W3C.

Una credencial v3.0 retallada mostra com de diferent es veu el sobre, tot i que les dades d’assoliment subjacents siguin conceptualment el mateix atorgament:

{
  "@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" }
}

Fixa’t que el camp issuer és un DID, no una URL, i que tot el document porta un bloc proof en lloc d’un punter verification. Això és la resolució de DID + les eines de signatura de VC esmentades anteriorment — feina d’enginyeria real, i feina que es malbarata si encara no hi ha res corrent avall que la consumeixi realment.

Idees errònies habituals que val la pena aclarir

• “v3.0 és més segur.” No necessàriament — tant signed v2.0 com v3.0 depenen de la verificació criptogràfica. L’avantatge de v3.0 és la identitat estandarditzada (DID) i la interoperabilitat de cartera, no una millora de seguretat respecte a signed v2.0.
• “v2.0 està obsolet.” No ho està. 1EdTech manté totes dues especificacions, i v2.0 continua sent la versió a què fan referència les plataformes i integracions que els emissors realment fan servir dia a dia.
• “Has de triar-ne una per a tot el programa.” No cal. Res impedeix que un emissor publiqui v2.0 per a ús general i afegeixi sortida v3.0 per a una integració específica amb un soci que ho requereixi — les dades d’atorgament subjacents no canvien, només la representació.

El camí de migració (i per què no cal triar per sempre)

El moviment pràctic per a gairebé tots els emissors: publica v2.0 ara, i tracta v3.0 com una addició, no un reemplaçament, quan un consumidor corrent avall específic ho demani. Algunes raons per les quals això funciona netament:

1. Els teus IDs de BadgeClass i Assertion no necessiten canviar quan afegeixis suport per a v3.0 més endavant — estàs afegint una segona representació, amb una forma diferent, del mateix atorgament subjacent, no migrant les credencials existents dels destinataris.
2. Els verificadors que només entenen v2.0 continuen funcionant exactament com abans.
3. Evites construir infraestructura DID i pipelines de signatura VC abans de tenir un requisit concret que els necessiti.

Aquesta és la mateixa lògica que fem servir internament a badges.ninja: cada atorgament surt com una Open Badge v2.0 — JSON-LD, verificació hosted en una URL estable /certify-badge/award/{guid}, llesta per a LinkedIn Add to Profile de sèrie — perquè això cobreix la gran majoria del que realment se’ls demana produir als emissors. Si el teu programa necessita més endavant sortida v3.0/CLR per a un soci institucional específic, això és una addició delimitada sobre un pipeline v2.0 que ja funciona, no una reescriptura.

Aquesta seqüenciació també et protegeix d’un risc més subtil: comprometre’t amb infraestructura DID abans de saber quin mètode DID esperen realment els teus socis. L’ecosistema VC encara no ha convergit en un sol mètode DID — did:web, did:key, i mètodes ancorats en llibres de registre apareixen tots a la pràctica, i triar el mètode equivocat per a un soci pilot vol dir haver de refer la feina d’identitat de l’emissor més endavant. Esperar un requisit anomenat vol dir descobrir quin mètode necessites realment abans de construir res.

Una comprovació ràpida per al teu propi programa

Fes-te aquestes tres preguntes abans de dedicar temps d’enginyeria a v3.0:

• Algun consumidor de les meves credencials — un ATS d’un ocupador, un organisme llicenciador, una institució sòcia — requereix explícitament sortida CLR 2.0 o VC del W3C? Si no, v2.0 ja et cobreix.
• Els meus destinataris necessiten guardar aquesta credencial en una aplicació de cartera digital, no només en un perfil web o a LinkedIn? Si no, v2.0 ja et cobreix.
• Estàs construint infraestructura de confiança entre emissors on la verificació hosted basada en URL genuïnament no n’hi ha prou? Si no, v2.0 ja et cobreix.

Si has respost “no” tres vegades, no vas endarrerit per publicar v2.0 el 2026 — estàs fent coincidir l’especificació amb l’ecosistema que realment la consumeix. Revisita la qüestió quan un soci o requisit de compliment específic demani v3.0 pel seu nom, no per una sensació general que “v3 és més nou”.

Per a més informació sobre com les dades de verificació de credencials es comparen amb formats de credencials més antics i no estàndard, consulta Blockchain Certificates vs Open Badges, que aprofundeix en els compromisos entre verificació i portabilitat des d’un altre angle.

---

Preparat per emetre la teva primera credencial verificable? Comença gratis a badges.ninja — dissenyador visual, pàgina pública de verificació, certificat en PDF, sortida Open Badge v2.0. No cal targeta de crèdit.