Open Badge v2 proti v3: Katero specifikacijo uporabiti danes?

Če leta 2026 vzpostavljate program za izdajanje digitalnih znački, boste že v prvi uri raziskovanja naleteli na to vprašanje: naj izdajate Open Badge v2.0 ali novejšo različico v3.0? Iskren odgovor je „odvisno od tega, kdo mora vaše značke prebrati” — kar pa ni ravno pomirjujoče, če morate odločitev sprejeti do petka. Zato si poglejmo, kaj se je med specifikacijama dejansko spremenilo, kdo danes kaj podpira in katero od njiju naj večina izdajateljev uporablja prav zdaj.

Kaj Open Badge v2.0 dejansko je

Open Badge v2.0 je specifikacija organizacije 1EdTech (nekdaj IMS Global), ki je hrbtenica digitalnega izdajanja znački že od leta 2017. Temelji na JSON-LD in je strukturirana okoli treh povezanih objektov:

• IssuerOrg — kdo je izdal značko (ime, URL, e-pošta, logotip)
• BadgeClass — sam tip značke (ime, opis, kriteriji, slika)
• Assertion — konkretna podelitev konkretnemu prejemniku (identiteta prejemnika, datum izdaje, dokazi, način preverjanja)

Assertion prejemnika kaže na BadgeClass, ta pa nazaj na IssuerOrg. Preverjanje poteka na enega od dveh načinov: gostovano (hosted; preverjevalec pridobi živ Assertion JSON s stabilnega URL-ja in zaupa domeni) ali podpisano (signed; Assertion nosi podpis JWS, ki ga preverjevalec preveri glede na javni ključ izdajatelja). Večina platform, tudi badges.ninja, privzeto uporablja gostovano preverjanje, pri čemer je podpisano na voljo kot možnost — ker je gostovano preprosteje implementirati in ga lažje ročno preveri tudi človek.

Tukaj je skrajšan Assertion v2.0, kakršnega dobite pri klicu 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" }
}

Prav ta struktura je razlog, da je v2.0 postal dejanski standard: dovolj je preprosta, da jo lahko implementirate v enem popoldnevu, obenem pa je to, kar skoraj vsak porabnik podatkov o značkah tudi pričakuje.

Gostovano proti podpisanemu preverjanju znotraj v2.0

Velja razumeti oba načina preverjanja znotraj same specifikacije v2.0, saj ljudje pogosto zamenjujejo trditev „v2.0 je manj varen kot v3.0” s trditvijo „gostovano preverjanje je manj varno kot podpisano”. To nista ista osi primerjave.

• Gostovano — verification.type je "hosted", id te Assertion pa je živ URL. Preverjevalec ta URL pridobi in preveri, ali se odgovor ujema; zaupanje izhaja iz nadzora nad domeno (npr. samo badges.ninja lahko objavlja na badges.ninja/certify-badge/award/...). To uporablja večina strani za preverjanje, namenjenih končnim uporabnikom, saj lahko človek preprosto klikne na povezavo.
• Podpisano — verification.type je "signed", Assertion pa nosi (ali referencira) podpis JWS nad vsebino. Preverjevalec pridobi javni ključ izdajatelja in preveri podpis neodvisno od tega, ali je kateri koli URL dosegljiv. To je po duhu bližje modelu v3.0, le brez plasti DID.

Minimalno preverjanje podpisane različice v Node.js izgleda takole:

import { jwtVerify, importJWK } from 'jose';

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

Če je vašemu programu pomembno, da značke ostanejo preverljive tudi, ko gre vaš API v vzdrževanje in za nekaj časa ni dosegljiv, vam podpisan v2.0 prinese večino prednosti trajnosti, ki jih ponuja v3.0 — brez uvajanja DID-jev.

Kaj Open Badge v3.0 spreminja

Open Badge v3.0 je prenova, zgrajena na modelu W3C Verifiable Credentials (VC) Data Model, ne pa postopna nadgradnja JSON-LD oblike specifikacije v2.0. Razlike, ki so v praksi pomembne:

• Kriptografsko podpisovanje privzeto. Vsaka poverilnica v3.0 je podpisana VC — ni več rezervne možnosti „gostovano, zaupaj URL-ju”. Preverjanje je vedno matematično, ne temelji na domeni.
• Identiteta izdajatelja na podlagi DID. Namesto objekta IssuerOrg z URL-jem in e-pošto je izdajatelj identificiran z decentraliziranim identifikatorjem (DID), ki se razreši v dokument z javnim ključem.
• Usklajenost s Comprehensive Learner Record (CLR) 2.0. v3.0 je zasnovan za sodelovanje s CLR, zato lahko ena sama poverilnica nosi podatke o dosežku poleg strukturiranih podrobnosti prepisa, kakršne pričakujejo porabniki CLR (kompetence, rezultati ocenjevanja, kontekst predmeta/semestra).
• Združljivost z digitalnimi denarnicami. Ker so poverilnice v3.0 standardne W3C VC, jih je mogoče hraniti v identitetnih denarnicah na enak način kot vozniško dovoljenje ali potrdilo o cepljenju — ne le prikazovati na spletni strani.

Skratka: v2.0 odgovarja na vprašanje „ali lahko človek ali preprost skript to poverilnico preveri”, v3.0 pa na vprašanje „ali lahko ta poverilnica sodeluje s širšim ekosistemom preverljivih poverilnic — denarnicami, DID-ji, formalnimi zapisi o učenju”.

Primerjava vzporedno

Zakaj uveljavljena baza še vedno teče na v2.0

To je del, ki za večino programov nagne odločitev: mesta, kjer si vaši prejemniki dejansko želijo prikazati svoje poverilnice, še vedno pričakujejo v2.0. Tok LinkedIn Add to Profile, Credly, Badgr in velika večina integracij sistemov za sledenje kandidatom (ATS) razčlenjujejo obliko Assertion/BadgeClass iz v2.0. Če je vaš cilj, da lahko prejemniki značko objavijo na LinkedInu, kadrovniki pa jo lahko s klikom preverijo, v2.0 ni zastarela oblika, s katero ste obtičali — je oblika, ki jo ekosistem trenutno govori.

To natanko isto napetost smo z vidika prejemnika obravnavali v članku LinkedIn Skill Assessments proti Open Badges — vrednost značke je v veliki meri odvisna od tega, kako zlahka se vklopi v mesta, kamor kadrovniki in kolegi že gledajo, danes pa je to infrastruktura, ki jo v pretežni meri oblikuje v2.0.

Kdaj v3.0 dejansko šteje

v3.0 ni le modna muha — rešuje resnične težave za specifične programe:

• Univerze in izdajatelji pod mandati CLR. Če izdajate značke vzporedno s formalnim sistemom prepisov ali državni/regionalni izobraževalni organ zahteva izhod, združljiv s CLR 2.0, vam vgrajena usklajenost v3.0 prihrani nameščanje polj CLR na Assertion v2.0.
• Programi, ki ciljajo na shranjevanje v digitalnih denarnicah. Če morajo vaši prejemniki poverilnico hraniti v aplikaciji denarnice namesto zgolj prikazovati na spletni strani, bo nativno delovala le W3C VC (torej v3.0).
• Izmenjava poverilnic med izdajatelji z zaupanjem na podlagi DID. Če gradite ali se pridružujete omrežju, kjer mora biti identiteta izdajatelja kriptografsko prenosljiva namesto „zaupaj temu URL-ju”, so DID-ji pravi gradnik.

Nič od naštetega ni pogost primer za programe usposabljanja, bootcampe ali izdajatelje strokovnega izpopolnjevanja leta 2026. Pogosti so pri institucijah z zahtevami po skladnosti ali interoperabilnosti, ki izrecno omenjajo CLR ali W3C VC.

Skrajšana poverilnica v3.0 pokaže, kako drugačna je ovojnica, čeprav so temeljni podatki o dosežku pojmovno ista podelitev:

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

Opazite, da je polje issuer DID, ne URL, in da celoten dokument namesto kazalca verification nosi blok proof. To je tisto razreševanje DID in orodje za podpisovanje VC, omenjeno zgoraj — resnično inženirsko delo, ki pa je zapravljeno, če ga trenutno še nihče na drugi strani sploh ne porablja.

Pogoste zmote, ki jih velja razjasniti

• „v3.0 je bolj varen.” Ne nujno — tako podpisan v2.0 kot v3.0 se zanašata na kriptografsko preverjanje. Prednost v3.0 je standardizirana identiteta (DID-ji) in interoperabilnost z denarnicami, ne varnostna nadgradnja glede na podpisan v2.0.
• „v2.0 je opuščen.” Ni. 1EdTech vzdržuje obe specifikaciji, v2.0 pa ostaja različica, na katero se sklicujejo platforme in integracije, ki jih izdajatelji dejansko uporabljajo vsak dan.
• „Za cel program morate izbrati eno od obeh.” Ni res. Nič ne preprečuje izdajatelju, da objavlja v2.0 za splošno rabo in doda izhod v3.0 za specifično integracijo s partnerjem, ki jo zahteva — osnovni podatki o podelitvi se ne spremenijo, spremeni se le predstavitev.

Pot migracije (in zakaj vam ni treba izbrati za vedno)

Praktična poteza za skoraj vsakega izdajatelja: zdaj dostavite v2.0, v3.0 pa obravnavajte kot dodatek, ne zamenjavo, ko to izrecno zahteva konkreten porabnik na drugi strani. Nekaj razlogov, zakaj to deluje brez zapletov:

1. Vaših identifikatorjev BadgeClass in Assertion ni treba spreminjati, ko kasneje dodate podporo za v3.0 — dodajate drugačno, drugače oblikovano predstavitev iste osnovne podelitve, ne migrirate obstoječih poverilnic prejemnikov.
2. Preverjevalci, ki razumejo samo v2.0, delujejo naprej popolnoma enako kot prej.
3. Izognete se gradnji infrastrukture DID in cevovodov za podpisovanje VC, preden imate konkretno zahtevo, ki ju resnično potrebuje.

To je ista logika, ki jo interno uporabljamo pri badges.ninja: vsaka podelitev gre ven kot Open Badge v2.0 — JSON-LD, gostovano preverjanje na stabilnem URL-ju /certify-badge/award/{guid}, pripravljeno za LinkedIn Add to Profile takoj iz škatle — ker to pokrije veliko večino tega, kar izdajatelji dejansko potrebujejo. Če vaš program kasneje potrebuje izhod v3.0/CLR za specifičnega institucionalnega partnerja, je to omejen dodatek na delujočem cevovodu v2.0, ne prenova.

To zaporedje vas obenem varuje pred subtilnejšim tveganjem: vezavo na infrastrukturo DID, preden veste, katero metodo DID vaši partnerji dejansko pričakujejo. Ekosistem VC se še ni poenotil okoli ene metode DID — did:web, did:key in metode, sidrane v verigi blokov, se v praksi vse pojavljajo, izbira napačne za pilotnega partnerja pa pomeni, da boste delo na identiteti izdajatelja kasneje morali ponoviti. Če počakate na poimensko zahtevo, ugotovite, katero metodo dejansko potrebujete, še preden karkoli zgradite.

Hiter test za vaš lasten program

Preden vložite inženirski čas v v3.0, si postavite tri vprašanja:

• Ali kateri koli porabnik vaših poverilnic — ATS delodajalca, licenčni organ, partnerska institucija — izrecno zahteva izhod CLR 2.0 ali W3C VC? Če ne, vas v2.0 pokriva.
• Ali morajo vaši prejemniki to poverilnico hraniti v aplikaciji digitalne denarnice, ne le v spletnem profilu ali na LinkedInu? Če ne, vas v2.0 pokriva.
• Ali gradite infrastrukturo zaupanja med izdajatelji, kjer gostovano preverjanje na podlagi URL-ja resnično ne zadošča? Če ne, vas v2.0 pokriva.

Če ste trikrat odgovorili z „ne”, z izdajanjem v2.0 leta 2026 niste v zaostanku — specifikacijo prilagajate ekosistemu, ki jo dejansko porablja. K vprašanju se vrnite, ko konkreten partner ali zahteva po skladnosti poimensko zahteva v3.0, ne na podlagi splošnega občutka, da je „v3 novejši”.

Za več o tem, kako podatki o preverjanju znački stojijo v primerjavi s starejšimi, nestandardnimi oblikami poverilnic, si oglejte Blockchain Certificates proti Open Badges, ki se v kompromise med preverjanjem in prenosljivostjo poglobi z drugega zornega kota.

---

Ste pripravljeni izdati svojo prvo preverljivo poverilnico? Začnite brezplačno na badges.ninja — vizualni oblikovalnik, javna stran za preverjanje, certifikat PDF, izhod Open Badge v2.0. Kreditna kartica ni potrebna.