Open Badge v2 vs v3 explicat: Ce specificație ar trebui să folosești astăzi?

Dacă pui la punct un program de acreditare în 2026, o să dai peste această întrebare chiar din prima oră de documentare: ar trebui să emiți Open Badge v2.0 sau noul v3.0? Răspunsul onest este „depinde cine trebuie să-ți citească insignele” — dar asta nu e o soluție mulțumitoare dacă tu ești cel care trebuie să decidă până vineri. Așa că hai să trecem prin ce s-a schimbat de fapt între cele două specificații, cine susține ce astăzi și pe care ar trebui să o folosească majoritatea emitenților chiar acum.

Ce este de fapt Open Badge v2.0

Open Badge v2.0 este specificația 1EdTech (fostă IMS Global) care a fost coloana vertebrală a acreditării digitale din 2017 încoace. Este construită pe JSON-LD și structurată în jurul a trei obiecte legate între ele:

• IssuerOrg — cine a emis credențialul (nume, URL, email, logo)
• BadgeClass — tipul de credențial în sine (nume, descriere, criterii, imagine)
• Assertion — acordarea specifică unui destinatar specific (identitatea destinatarului, data issuedOn, dovezi, metoda de verificare)

Assertion-ul unui destinatar face trimitere la o BadgeClass, care la rândul ei face trimitere înapoi la un IssuerOrg. Verificarea se face în unul din două moduri: hosted (verificatorul preia JSON-ul live al Assertion-ului de la un URL stabil și are încredere în domeniu) sau signed (Assertion-ul poartă o semnătură JWS pe care verificatorul o confirmă folosind cheia publică publicată de emitent). Majoritatea platformelor, inclusiv badges.ninja, folosesc implicit verificarea hosted, cu signed ca opțiune, pentru că hosted e mai simplu de implementat și mai ușor de verificat rapid de către un om.

Iată un Assertion v2.0 simplificat, genul de răspuns pe care l-ai primi la un apel 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" }
}

Această structură e motivul pentru care v2.0 a devenit standardul de facto: e suficient de simplă încât s-o implementezi într-o după-amiază și e exact ce se așteaptă să vadă aproape orice consumator de date despre insigne.

Verificarea hosted vs signed în v2.0

Merită să înțelegi cele două moduri de verificare din interiorul v2.0, pentru că oamenii confundă adesea „v2.0 e mai puțin sigur decât v3.0” cu „verificarea hosted e mai puțin sigură decât signed.” Nu e vorba despre aceeași axă.

• Hosted — verification.type este "hosted", iar id-ul Assertion-ului este un URL live. Un verificator preia acel URL și verifică dacă răspunsul se potrivește; încrederea vine din controlul domeniului (de exemplu, doar badges.ninja poate publica la badges.ninja/certify-badge/award/...). Asta folosesc majoritatea paginilor de verificare orientate spre public, pentru că un om poate pur și simplu să dea click pe link.
• Signed — verification.type este "signed", iar Assertion-ul poartă (sau face referire la) o semnătură JWS peste payload. Un verificator rezolvă cheia publică a emitentului și verifică semnătura independent de accesibilitatea vreunui URL. Asta se apropie ca spirit de modelul v3.0, doar fără stratul de DID.

O verificare minimală de tip signed în Node arată așa:

import { jwtVerify, importJWK } from 'jose';

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

Dacă programul tău ține ca insignele să rămână verificabile chiar și după ce API-ul tău e offline pentru mentenanță, v2.0 semnat îți oferă cea mai mare parte din beneficiul de durabilitate al v3.0, fără să adopți DID-uri.

Ce schimbă Open Badge v3.0

Open Badge v3.0 este o rescriere construită peste W3C Verifiable Credentials (VC) Data Model, nu o actualizare incrementală a formei JSON-LD din v2.0. Diferențele care contează în practică:

• Semnare criptografică implicită. Fiecare credențial v3.0 este un VC semnat — nu există un fallback de tip „hosted, ai încredere în URL”. Verificarea este întotdeauna matematică, nu bazată pe domeniu.
• Identitate a emitentului bazată pe DID. În loc de un obiect IssuerOrg cu URL și email, emitentul este identificat printr-un Decentralized Identifier (DID), care se rezolvă la un document cu chei publice.
• Aliniere cu Comprehensive Learner Record (CLR) 2.0. v3.0 a fost proiectat să interopereze cu CLR, astfel încât un singur credențial poate purta date despre realizare plus tipul de detalii structurate de tip transcript pe care le așteaptă consumatorii de CLR (competențe, rezultate ale evaluărilor, context de semestru/curs).
• Compatibilitate cu portofele digitale. Pentru că credențialele v3.0 sunt VC-uri W3C standard, ele pot fi păstrate în portofele de identitate la fel cum poate fi un permis de conducere sau un certificat de vaccinare — nu doar afișate pe o pagină web.

Pe scurt: v2.0 răspunde la întrebarea „poate un om sau un script simplu să verifice acest credențial”, iar v3.0 răspunde la „poate acest credențial să interopereze cu ecosistemul mai larg de verifiable credentials — portofele, DID-uri, registre formale de învățare (learner records)“.

Comparație directă

De ce baza instalată încă rulează pe v2.0

Asta e partea care înclină decizia pentru majoritatea programelor: locurile unde destinatarii tăi chiar vor să-și afișeze credențialele încă așteaptă v2.0. Fluxul Add to Profile de pe LinkedIn, Credly, Badgr și marea majoritate a integrărilor de tip applicant-tracking-system interpretează forma Assertion/BadgeClass din v2.0. Dacă scopul tău este „destinatarii pot posta asta pe LinkedIn, iar recrutorii pot da click pentru a-l verifica”, v2.0 nu e un format vechi de care ești blocat — e formatul pe care îl vorbește ecosistemul în prezent.

Am acoperit exact această tensiune, din perspectiva destinatarului, în LinkedIn Skill Assessments vs Open Badges — valoarea unei insigne este în mare parte o funcție a cât de ușor se integrează în locurile unde recrutorii și colegii se uită deja, iar astăzi asta înseamnă, copleșitor, infrastructură în forma v2.0.

Când chiar contează v3.0

v3.0 nu e doar hype — rezolvă probleme reale pentru programe specifice:

• Universități și emitenți sub mandate CLR. Dacă emiți în paralel cu un sistem formal de transcript, sau dacă un organism educațional de stat/regional cere output compatibil cu CLR 2.0, alinierea integrată a v3.0 te scutește de a atașa forțat câmpuri CLR pe un Assertion v2.0.
• Programe orientate spre stocarea în portofele digitale. Dacă destinatarii tăi trebuie să păstreze credențialul într-o aplicație de portofel, nu doar să-l afișeze pe o pagină web, doar un VC W3C (adică v3.0) va funcționa acolo nativ.
• Schimb de credențiale între emitenți, cu încredere bazată pe DID. Dacă construiești sau te alături unei rețele în care identitatea emitentului trebuie să fie portabilă criptografic, nu de tipul „ai încredere în acest URL”, DID-urile sunt primitiva potrivită.

Niciunul dintre aceste cazuri nu e comun pentru un program de training, un bootcamp sau un emitent de dezvoltare profesională în 2026. Sunt comune pentru instituții cu cerințe de conformitate sau interoperabilitate care numesc explicit CLR sau VC-uri W3C.

Un credențial v3.0 simplificat arată cât de diferit e „plicul”, chiar și atunci când datele de bază despre realizare reprezintă conceptual aceeași acordare:

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

Observă că field-ul issuer este un DID, nu un URL, iar întregul document poartă un bloc proof în loc de un pointer verification. Astea sunt exact rezolvarea de DID-uri și uneltele de semnare VC menționate mai sus — muncă reală de inginerie, muncă ce se irosește dacă nimic din aval nu o consumă încă de fapt.

Concepții greșite frecvente, demontate

• „v3.0 e mai sigur.” Nu neapărat — atât v2.0 semnat, cât și v3.0 se bazează pe verificare criptografică. Avantajul v3.0 este identitatea standardizată (DID-urile) și interoperabilitatea cu portofelele, nu un upgrade de securitate față de v2.0 semnat.
• „v2.0 e depreciat.” Nu este. 1EdTech întreține ambele specificații, iar v2.0 rămâne versiunea la care fac referire platformele și integrările pe care emitenții le folosesc de fapt zi de zi.
• „Trebuie să alegi una singură pentru tot programul.” Nu trebuie. Nimic nu-l oprește pe un emitent să publice v2.0 pentru uz general și să adauge output v3.0 pentru o integrare cu un anumit partener care îl cere — datele de bază despre acordare nu se schimbă, doar reprezentarea.

Calea de migrare (și de ce nu trebuie să alegi pentru totdeauna)

Mișcarea practică pentru aproape orice emitent: livrează v2.0 acum și tratează v3.0 ca pe o adăugire, nu ca pe o înlocuire, atunci când un consumator specific din aval o cere. Câteva motive pentru care asta funcționează curat:

1. ID-urile BadgeClass și Assertion nu trebuie să se schimbe atunci când adaugi suport v3.0 mai târziu — adaugi o a doua reprezentare, cu formă diferită, a aceleiași acordări de bază, nu migrezi credențialele destinatarilor existenți.
2. Verificatorii care înțeleg doar v2.0 continuă să funcționeze exact ca înainte.
3. Eviți să construiești infrastructură DID și pipeline-uri de semnare VC înainte să ai o cerință concretă care să le necesite.

Asta e exact logica pe care o folosim intern la badges.ninja: fiecare acordare iese ca un Open Badge v2.0 — JSON-LD, verificare hosted la un URL stabil /certify-badge/award/{guid}, gata din start pentru LinkedIn Add to Profile — pentru că asta acoperă marea majoritate a ceea ce li se cere de fapt emitenților să producă. Dacă programul tău are nevoie mai târziu de output v3.0/CLR pentru un anumit partener instituțional, asta e o adăugire limitată peste un pipeline v2.0 funcțional, nu o rescriere.

Această ordine te protejează și de un risc mai subtil: să te angajezi în infrastructură DID înainte să știi ce metodă DID așteaptă de fapt partenerii tăi. Ecosistemul VC nu a convers către o singură metodă DID — did:web, did:key și metodele ancorate pe ledger apar toate în practică, iar alegerea greșită pentru un partener-pilot înseamnă să refaci mai târziu munca de identitate a emitentului. Așteptarea unei cerințe numite explicit înseamnă că afli ce metodă îți trebuie de fapt înainte să construiești orice.

Un test rapid pentru propriul tău program

Pune-ți aceste trei întrebări înainte să cheltuiești timp de inginerie pe v3.0:

• Vreun consumator al credențialelor mele — un ATS de angajator, un board de licențiere, o instituție parteneră — cere explicit output CLR 2.0 sau VC W3C? Dacă nu, v2.0 te acoperă.
• Destinatarii mei trebuie să păstreze acest credențial într-o aplicație de portofel digital, nu doar într-un profil web sau pe LinkedIn? Dacă nu, v2.0 te acoperă.
• Construiesc infrastructură de încredere între emitenți, unde verificarea hosted bazată pe URL chiar nu e suficientă? Dacă nu, v2.0 te acoperă.

Dacă ai răspuns „nu” de trei ori, nu ești în urmă livrând v2.0 în 2026 — potrivești specificația cu ecosistemul care chiar o consumă. Revino asupra întrebării atunci când un partener specific sau o cerință de conformitate cere v3.0 pe nume, nu pe baza unei senzații generale că „v3 e mai nou”.

Pentru mai multe despre cum rezistă datele de verificare a insignelor în fața unor formate de credențiale mai vechi și nestandardizate, vezi Blockchain Certificates vs Open Badges, care aprofundează compromisurile de verificare și portabilitate dintr-un unghi diferit.

---

Ești gata să emiți primul tău credențial verificabil? Începe gratuit pe badges.ninja — designer vizual, pagină publică de verificare, certificat PDF, output Open Badge v2.0. Nu e nevoie de card de credit.