Open Badge v2 vs v3 objašnjeno: Koju specifikaciju biste trebali koristiti danas?

Ako 2026. pokrećete program izdavanja vjerodajnica, na ovo ćete pitanje naići već u prvom satu istraživanja: trebate li izdavati Open Badge v2.0 ili noviji v3.0? Iskren odgovor glasi „ovisi o tome tko mora čitati vaše vjerodajnice” — no to nije baš zadovoljavajuće ako ste vi ta osoba koja mora odlučiti do petka. Zato prođimo kroz ono što se stvarno promijenilo između te dvije specifikacije, tko danas što podržava i koju bi većina izdavatelja trebala koristiti upravo sada.

Što Open Badge v2.0 zapravo jest

Open Badge v2.0 specifikacija je organizacije 1EdTech (nekadašnji IMS Global) koja je okosnica digitalnog izdavanja vjerodajnica još od 2017. godine. Izgrađena je na JSON-LD-u i strukturirana oko tri povezana objekta:

• IssuerOrg — tko je izdao vjerodajnicu (naziv, URL, e-mail, logotip)
• BadgeClass — sam tip vjerodajnice (naziv, opis, kriteriji, slika)
• Assertion — konkretna dodjela konkretnom primatelju (identitet primatelja, datum izdavanja issuedOn, dokazi, metoda provjere)

Primateljev Assertion upućuje na BadgeClass, koji pak upućuje natrag na IssuerOrg. Provjera se odvija na jedan od dva načina: hosted (onaj tko provjerava dohvaća živi Assertion JSON sa stabilnog URL-a i vjeruje domeni) ili signed (Assertion nosi JWS potpis koji provjeravatelj provjerava naspram javno objavljenog javnog ključa izdavatelja). Većina platformi, uključujući badges.ninja, po zadanome koristi hosted provjeru uz signed kao opciju, jer je hosted jednostavnija za implementaciju i lakša za brzu provjeru „na oko”.

Evo skraćenog v2.0 Assertiona, onoga što biste dobili kao odgovor na poziv 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" }
}

Upravo je zbog te strukture v2.0 postao de facto standard: dovoljno je jednostavan da ga implementirate za jedno poslijepodne, a ujedno je i ono što gotovo svaki potrošač podataka o značkama očekuje vidjeti.

Hosted naspram signed provjere unutar v2.0

Vrijedi razumjeti ta dva načina provjere unutar samog v2.0, jer ljudi često miješaju tvrdnju „v2.0 je manje siguran od v3.0” s tvrdnjom „hosted provjera je manje sigurna od signed provjere”. To nisu ista mjerila.

• Hosted — verification.type je "hosted", a id Assertiona je živi URL. Provjeravatelj dohvaća taj URL i provjerava odgovara li odgovor; povjerenje dolazi iz kontrole nad domenom (npr. samo badges.ninja može objavljivati na badges.ninja/certify-badge/award/...). Ovo koristi većina korisnički okrenutih stranica za provjeru jer čovjek jednostavno može kliknuti na poveznicu.
• Signed — verification.type je "signed", a Assertion nosi (ili referencira) JWS potpis nad payloadom. Provjeravatelj razrješava javni ključ izdavatelja i provjerava potpis neovisno o tome je li ikakav URL dostupan. Ovo je duhom bliže v3.0 modelu, samo bez DID sloja.

Minimalna provjera signed verifikacije u Node-u izgleda ovako:

import { jwtVerify, importJWK } from 'jose';

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

Ako je vašem programu stalo do toga da vjerodajnice ostanu provjerljive čak i nakon što vaš API ode offline zbog održavanja, signed v2.0 vam donosi većinu prednosti trajnosti koje nudi v3.0, a da pritom ne morate usvojiti DID-ove.

Što Open Badge v3.0 mijenja

Open Badge v3.0 je iznova napisan na temelju W3C Verifiable Credentials (VC) Data Modela, a ne postupna nadogradnja JSON-LD oblika iz v2.0. Razlike koje su bitne u praksi:

• Kriptografsko potpisivanje po zadanome. Svaka v3.0 vjerodajnica je potpisani VC — ne postoji „hosted, vjeruj URL-u” rezervni način. Provjera je uvijek matematička, a ne temeljena na domeni.
• Identitet izdavatelja temeljen na DID-u. Umjesto IssuerOrg objekta s URL-om i e-mailom, izdavatelj se identificira putem decentraliziranog identifikatora (DID), koji se razrješava u dokument s javnim ključem.
• Usklađenost s Comprehensive Learner Recordom (CLR) 2.0. v3.0 je osmišljen za interoperabilnost s CLR-om, pa jedna vjerodajnica može nositi podatke o postignuću plus onu vrstu strukturiranih detalja transkripta koje CLR potrošači očekuju (kompetencije, rezultati procjena, kontekst semestra/kolegija).
• Kompatibilnost s digitalnim novčanicima. Budući da su v3.0 vjerodajnice standardni W3C VC-ovi, mogu se čuvati u novčanicima za identitet na isti način kao vozačka dozvola ili potvrda o cijepljenju — ne samo prikazivati na web stranici.

Ukratko: v2.0 odgovara na pitanje „može li čovjek ili jednostavna skripta provjeriti ovu vjerodajnicu”, a v3.0 odgovara na pitanje „može li ova vjerodajnica biti interoperabilna sa širim ekosustavom provjerljivih vjerodajnica — novčanicima, DID-ovima, formalnim evidencijama učenja”.

Usporedba jedno pored drugog

Zašto postojeća baza korisnika i dalje radi na v2.0

Ovo je dio koji za većinu programa preteže odluku: mjesta na kojima vaši primatelji zapravo žele da se njihove vjerodajnice pojave i dalje očekuju v2.0. LinkedInov tijek Add to Profile, Credly, Badgr te velika većina integracija sustava za praćenje kandidata (ATS) parsiraju v2.0 oblik Assertion/BadgeClass. Ako vam je cilj „primatelji mogu ovo objaviti na LinkedInu, a regruteri mogu kliknuti kroz i provjeriti to”, v2.0 nije zastarjeli format u kojem ste zaglavili — to je format kojim ekosustav trenutno govori.

Upravo smo tu napetost, gledano iz perspektive primatelja, obradili u članku LinkedIn Skill Assessments vs Open Badges — vrijednost značke uvelike ovisi o tome koliko se lako uklapa u mjesta na kojima regruteri i kolege već gledaju, a danas je to pretežno infrastruktura oblikovana prema v2.0.

Kada je v3.0 zaista bitan

v3.0 nije puki hype — rješava stvarne probleme za specifične programe:

• Sveučilišta i izdavatelji pod CLR mandatima. Ako izdajete vjerodajnice usporedno s formalnim sustavom transkripata, ili ako državno/regionalno obrazovno tijelo zahtijeva izlaz kompatibilan s CLR-om 2.0, ugrađena usklađenost v3.0 sprječava vas da CLR polja morate naknadno „zalijepiti” na v2.0 Assertion.
• Programi usmjereni na pohranu u digitalnim novčanicima. Ako vaši primatelji trebaju čuvati vjerodajnicu u aplikaciji-novčaniku, a ne samo je prikazivati na web stranici, ondje nativno funkcionira jedino W3C VC (tj. v3.0).
• Razmjena vjerodajnica između izdavatelja s povjerenjem temeljenim na DID-u. Ako gradite ili se pridružujete mreži u kojoj identitet izdavatelja mora biti kriptografski prenosiv, a ne „vjeruj ovom URL-u”, DID-ovi su pravi gradivni element za to.

Nijedan od tih slučajeva nije uobičajen za edukacijski program, bootcamp ili izdavatelja iz područja profesionalnog usavršavanja u 2026. godini. Uobičajeni su za institucije s regulatornim zahtjevima ili zahtjevima interoperabilnosti koji izričito navode CLR ili W3C VC-ove.

Skraćena v3.0 vjerodajnica pokazuje koliko drukčije izgleda omotnica, čak i kada su temeljni podaci o postignuću konceptualno ista dodjela:

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

Primijetite da je polje izdavatelja DID, a ne URL, te da cijeli dokument nosi blok proof umjesto pokazivača verification. To je ono razrješavanje DID-ova + alati za potpisivanje VC-ova spomenuti gore — stvaran inženjerski posao, i posao koji je uzaludan ako ga još nitko dalje u lancu ne konzumira.

Uobičajene zablude vrijedne razjašnjenja

• „v3.0 je sigurniji.” Nije nužno tako — i signed v2.0 i v3.0 oslanjaju se na kriptografsku provjeru. Prednost v3.0 leži u standardiziranom identitetu (DID-ovi) i interoperabilnosti s novčanicima, a ne u sigurnosnoj nadogradnji u odnosu na signed v2.0.
• „v2.0 je zastario.” Nije. 1EdTech održava obje specifikacije, a v2.0 ostaje verzija na koju se referiraju platforme i integracije koje izdavatelji zapravo svakodnevno koriste.
• „Morate odabrati jednu verziju za cijeli program.” Ne morate. Ništa ne sprječava izdavatelja da objavljuje v2.0 za opću upotrebu i doda v3.0 izlaz za određenu integraciju s partnerom koja to zahtijeva — temeljni podaci o dodjeli se ne mijenjaju, mijenja se samo prikaz.

Put migracije (i zašto ne morate birati zauvijek)

Praktičan potez za gotovo svakog izdavatelja: odmah krenite s v2.0, a v3.0 tretirajte kao dodatak, a ne zamjenu, kada to izričito zatraži konkretan potrošač dalje u lancu. Nekoliko razloga zašto to čisto funkcionira:

1. Vaši ID-jevi BadgeClassa i Assertiona ne moraju se mijenjati kada kasnije dodate podršku za v3.0 — dodajete drugi, drukčije oblikovan prikaz iste temeljne dodjele, a ne migrirate postojeće vjerodajnice primatelja.
2. Provjeravatelji koji razumiju samo v2.0 nastavljaju raditi potpuno isto kao i prije.
3. Izbjegavate izgradnju DID infrastrukture i pipelinea za potpisivanje VC-ova prije nego što imate konkretan zahtjev koji ih traži.

Ovo je ista logika koju interno koristimo u badges.ninja: svaka dodjela izlazi kao v2.0 Open Badge — JSON-LD, hosted provjera na stabilnom /certify-badge/award/{guid} URL-u, LinkedIn Add to Profile spreman odmah po defaultu — jer to pokriva ogromnu većinu onoga što se od izdavatelja stvarno traži da proizvedu. Ako vaš program kasnije zatreba v3.0/CLR izlaz za konkretnog institucionalnog partnera, to je ograničeni dodatak na vrhu već funkcionalnog v2.0 pipelinea, a ne prepisivanje iznova.

Takav redoslijed vas štiti i od suptilnijeg rizika: obvezivanja na DID infrastrukturu prije nego što znate koju metodu DID-a vaši partneri zapravo očekuju. Ekosustav VC-ova još se nije usuglasio oko jedne metode DID-a — did:web, did:key i metode usidrene u ledgeru sve se pojavljuju u praksi, a odabir pogrešne za pilot-partnera znači da ćete kasnije morati iznova raditi posao oko identiteta izdavatelja. Čekanje na imenovani zahtjev znači da ćete saznati koju metodu zaista trebate prije nego što išta izgradite.

Brza provjera za vaš program

Postavite si ova tri pitanja prije nego uložite inženjersko vrijeme u v3.0:

• Zahtijeva li itko tko konzumira moje vjerodajnice — ATS poslodavca, licencirajuće tijelo, partnerska institucija — izričito CLR 2.0 ili W3C VC izlaz? Ako je odgovor ne, v2.0 vas pokriva.
• Trebaju li moji primatelji čuvati ovu vjerodajnicu u aplikaciji digitalnog novčanika, a ne samo na web profilu ili LinkedInu? Ako je odgovor ne, v2.0 vas pokriva.
• Gradim li infrastrukturu povjerenja između izdavatelja gdje hosted provjera temeljena na URL-u zaista nije dovoljna? Ako je odgovor ne, v2.0 vas pokriva.

Ako ste tri puta odgovorili „ne”, time što u 2026. isporučujete v2.0 niste u zaostatku — vi samo prilagođavate specifikaciju ekosustavu koji je stvarno konzumira. Vratite se na to pitanje kada konkretan partner ili regulatorni zahtjev izričito zatraži v3.0 po imenu, a ne na temelju općeg dojma da je „v3 noviji”.

Za više o tome kako podaci o provjeri značaka stoje u odnosu na starije, nestandardne formate vjerodajnica, pogledajte Blockchain Certificates vs Open Badges, koji iz drugog kuta analizira kompromise vezane uz provjeru i prenosivost.

---

Spremni izdati svoju prvu provjerljivu vjerodajnicu? Započnite besplatno na badges.ninja — vizualni dizajner, javna stranica za provjeru, PDF certifikat, Open Badge v2.0 izlaz. Kreditna kartica nije potrebna.