Open Badge v2 vs v3 selgitatud: millist spetsifikatsiooni peaksid täna kasutama?

Kui sa sead 2026. aastal üles tunnistusprogrammi, jõuad selle küsimuseni juba esimese uurimistunni jooksul: kas anda välja Open Badge v2.0 või uuem v3.0? Aus vastus on „see sõltub sellest, kes peab sinu tunnistusi lugema” — aga see ei ole rahuldav, kui just sina pead reedeks otsuse tegema. Seega vaatame läbi, mis kahe spetsifikatsiooni vahel tegelikult muutus, kes mida täna toetab ja millist enamik väljaandjaid peaks praegu kasutusele võtma.

Mis Open Badge v2.0 tegelikult on

Open Badge v2.0 on 1EdTechi (endine IMS Global) spetsifikatsioon, mis on olnud digitaalse tunnistamise selgroog alates 2017. aastast. See põhineb JSON-LD-l ja on üles ehitatud kolme omavahel seotud objekti ümber:

• IssuerOrg — kes tunnistuse väljastas (nimi, URL, e-post, logo)
• BadgeClass — tunnistuse tüüp ise (nimi, kirjeldus, kriteeriumid, pilt)
• Assertion — konkreetne tunnustus konkreetsele saajale (saaja identiteet, väljastamise kuupäev, tõendid, kinnitamise meetod)

Saaja Assertion viitab BadgeClass’ile, mis omakorda viitab tagasi IssuerOrg’ile. Kinnitamine toimub kahel viisil: hostitud (kinnitaja toob elava Assertion JSON-i stabiilselt URL-ilt ja usaldab domeeni) või allkirjastatud (Assertion kannab JWS-allkirja, mida kinnitaja kontrollib väljaandja avaldatud avaliku võtme vastu). Enamik platvorme, sealhulgas badges.ninja, kasutab vaikimisi hostitud kinnitamist, pakkudes allkirjastamist valikuna, sest hostitud viis on lihtsam rakendada ja inimesel lihtsam pilkupüüdvalt kontrollida.

Siin on kärbitud v2.0 Assertion, sarnane sellega, mida saaksid tagasi GET /awards/{id} päringust:

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

See struktuur on põhjus, miks v2.0-st on saanud de facto standard: seda on piisavalt lihtne rakendada ühe pärastlõunaga ning see on see, mida peaaegu iga märgiandmete tarbija ootab näha.

Hostitud vs allkirjastatud kinnitamine v2.0-s

Tasub mõista neid kahte kinnitusrežiimi v2.0 sees, sest inimesed ajavad sageli segamini väited „v2.0 on vähem turvaline kui v3.0” ja „hostitud kinnitamine on vähem turvaline kui allkirjastatud.” Need ei ole sama telg.

• Hostitud — verification.type on "hosted" ja Assertioni id on elav URL. Kinnitaja toob selle URL-i ja kontrollib, kas vastus sobib; usaldus tuleb domeeni kontrollimisest (nt ainult badges.ninja saab avaldada aadressile badges.ninja/certify-badge/award/...). Seda kasutavad enamik tarbijale suunatud kinnituslehti, sest inimene saab lihtsalt lingile klõpsata.
• Allkirjastatud — verification.type on "signed" ja Assertion kannab (või viitab) JWS-allkirjale sisu üle. Kinnitaja lahendab väljaandja avaliku võtme ja kontrollib allkirja sõltumatult sellest, kas mõni URL on kättesaadav. See on vaimult lähemal v3.0 mudelile, ainult ilma DID-kihita.

Minimaalne allkirjastatud kinnituse kontroll Node’is näeb välja selline:

import { jwtVerify, importJWK } from 'jose';

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

Kui sinu programmile on oluline, et tunnistused jääksid kinnitatavaks ka pärast seda, kui sinu API läheb hoolduseks maha, annab allkirjastatud v2.0 sulle enamiku v3.0 vastupidavuse eelistest, ilma et peaksid DID-e kasutusele võtma.

Mida Open Badge v3.0 muudab

Open Badge v3.0 on ümberkirjutus W3C Verifiable Credentials (VC) andmemudeli peal, mitte v2.0 JSON-LD kuju astmeline uuendus. Erinevused, mis praktikas loevad:

• Krüptograafiline allkirjastamine vaikimisi. Iga v3.0 tunnistus on allkirjastatud VC — ei ole „hostitud, usalda URL-i” varianti. Kinnitamine on alati matemaatiline, mitte domeenipõhine.
• DID-põhine väljaandja identiteet. URL-i ja e-postiga IssuerOrg objekti asemel tuvastatakse väljaandja detsentraliseeritud identifikaatori (DID) abil, mis lahendub avaliku võtme dokumendiks.
• Kooskõla Comprehensive Learner Record’iga (CLR) 2.0. v3.0 on kavandatud koostööks CLR-iga, seega saab üks tunnistus kanda nii saavutusandmeid kui ka struktureeritud transkriptsiooni detaile, mida CLR-i tarbijad ootavad (kompetentsid, hindamistulemused, kursuse/perioodi kontekst).
• Digitaalse rahakoti ühilduvus. Kuna v3.0 tunnistused on standardsed W3C VC-d, saab neid hoida identiteedirahakottides samamoodi nagu juhiluba või vaktsineerimistõendit — mitte ainult veebilehel kuvada.

Lühidalt: v2.0 vastab küsimusele „kas inimene või lihtne skript saab seda tunnistust kinnitada,” ja v3.0 vastab küsimusele „kas see tunnistus suudab suhelda laiema kinnitatavate tunnistuste ökosüsteemiga — rahakotid, DID-id, formaalsed õppija kirjed.”

Kõrvutav võrdlus

Miks olemasolev baas töötab endiselt v2.0 peal

See on osa, mis kallutab otsuse enamiku programmide jaoks: kohad, kus sinu saajad tegelikult tahavad, et nende tunnistused oleksid näha, ootavad endiselt v2.0-t. LinkedIni Add to Profile voog, Credly, Badgr ja valdav enamik kandidaadijälgimissüsteemide integratsioone parsivad v2.0 Assertion/BadgeClass kuju. Kui su eesmärk on „saajad saavad selle LinkedInisse postitada ja värbajad saavad läbi klikkida, et seda kinnitada,” ei ole v2.0 vananenud formaat, millega oled kinni — see on formaat, mida ökosüsteem praegu räägib.

Käsitlesime täpselt sama pinget saaja vaatenurgast artiklis LinkedIn Skill Assessments vs Open Badges — märgi väärtus on suuresti funktsioon sellest, kui lihtsalt see sobitub kohtadega, kust värbajad ja kolleegid juba niigi vaatavad, ja täna on need valdavalt v2.0 kujuga infrastruktuurid.

Millal v3.0 tegelikult loeb

v3.0 ei ole hüpe — see lahendab reaalseid probleeme konkreetsete programmide jaoks:

• Ülikoolid ja väljaandjad CLR-kohustuste all. Kui väljastad tunnistusi koos ametliku transkriptsioonisüsteemiga või osariigi/piirkondlik haridusasutus nõuab CLR 2.0-ühilduvat väljundit, säästab v3.0 sisseehitatud kooskõla sind CLR-väljade poltimisest v2.0 Assertioni külge.
• Programmid, mis sihivad digitaalse rahakoti hoidmist. Kui su saajad peavad tunnistust hoidma rahakoti rakenduses, mitte ainult veebilehel kuvama, töötab seal loomulikult ainult W3C VC (ehk v3.0).
• Väljaandjatevaheline tunnistuste vahetus DID-põhise usaldusega. Kui ehitad või liitud võrgustikuga, kus väljaandja identiteet peab olema krüptograafiliselt kaasaskantav, mitte „usalda seda URL-i,” on DID-id õige alusühik.

Ükski neist ei ole 2026. aastal levinud juhtum koolitusprogrammi, bootcamp’i või erialase täiendõppe väljaandja jaoks. Need on levinud institutsioonidele, kellel on vastavus- või koostalitlusnõuded, mis nimetavad konkreetselt CLR-i või W3C VC-sid.

Kärbitud v3.0 tunnistus näitab, kui erinev ümbrik välja näeb, isegi kui alusandmed on kontseptuaalselt sama tunnustus:

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

Pane tähele, et väljaandja väli on DID, mitte URL, ja kogu dokument kannab proof-plokki verification-viida asemel. See ongi eespool mainitud DID lahendamise + VC allkirjastamise tööriistastik — reaalne inseneritöö, mis läheb raisku, kui keegi allavoolu seda veel ei tarbi.

Levinud väärarusaamad, mis väärivad selgitamist

• „v3.0 on turvalisem.” Mitte tingimata — nii allkirjastatud v2.0 kui ka v3.0 tuginevad krüptograafilisele kinnitamisele. v3.0 eelis on standardiseeritud identiteet (DID-id) ja rahakoti koostalitlus, mitte turvauuendus allkirjastatud v2.0 suhtes.
• „v2.0 on aegunud.” Ei ole. 1EdTech hooldab mõlemat spetsifikatsiooni ja v2.0 jääb versiooniks, millele viitavad platvormid ja integratsioonid, mida väljaandjad igapäevaselt tegelikult kasutavad.
• „Pead kogu programmi jaoks ühe valima.” Ei pea. Miski ei takista väljaandjal avaldada v2.0-t üldiseks kasutuseks ja lisada v3.0 väljundit konkreetse partneriintegratsiooni jaoks, mis seda nõuab — alusandmed ei muutu, muutub ainult esitusviis.

Migratsiooniteekond (ja miks sa ei pea igaveseks valima)

Praktiline samm peaaegu iga väljaandja jaoks: anna praegu välja v2.0 ja käsitle v3.0-t lisandusena, mitte asendusena, kui konkreetne allavoolu tarbija seda nõuab. Mõned põhjused, miks see puhtalt toimib:

1. Sinu BadgeClass’i ja Assertioni ID-d ei pea muutuma, kui lisad hiljem v3.0 tuge — lisad sama alusnev tunnustuse teise, erineva kujuga esituse, mitte ei migreeri olemasolevate saajate tunnistusi.
2. Kinnitajad, kes mõistavad ainult v2.0-t, jätkavad tööd täpselt nagu enne.
3. Väldid DID-infrastruktuuri ja VC allkirjastamise torustike ehitamist enne, kui sul on konkreetne nõue, mis neid vajab.

See on sama loogika, mida kasutame sisemiselt badges.ninjas: iga tunnustus väljastatakse v2.0 Open Badge’ina — JSON-LD, hostitud kinnitamine stabiilsel /certify-badge/award/{guid} URL-il, LinkedIn Add to Profile valmis kohe karbist — sest see katab valdava enamuse sellest, mida väljaandjatelt tegelikult küsitakse. Kui su programm hiljem vajab v3.0/CLR väljundit konkreetse institutsionaalse partneri jaoks, on see piiritletud lisandus toimivale v2.0 torustikule, mitte ümberkirjutus.

See järjestus kaitseb sind ka peenema riski eest: DID-infrastruktuuri kohustumine enne, kui tead, millist DID-meetodit su partnerid tegelikult ootavad. VC ökosüsteem ei ole ühele DID-meetodile koondunud — did:web, did:key ja plokiahelaga ankurdatud meetodid esinevad kõik looduses, ning vale meetodi valimine pilootpartneri jaoks tähendab väljaandja-identiteedi töö hiljem ümbertegemist. Nimelise nõude ootamine tähendab, et saad teada, millist meetodit tegelikult vajad, enne kui midagi ehitad.

Kiire enesekontroll sinu enda programmi jaoks

Küsi need kolm küsimust enne, kui kulutad inseneriaega v3.0-le:

• Kas mõni minu tunnistuste tarbija — tööandja ATS, litsentseerimisamet, partnerinstitutsioon — nõuab sõnaselgelt CLR 2.0 või W3C VC väljundit? Kui ei, katab v2.0 sind.
• Kas mu saajad peavad seda tunnistust hoidma digitaalse rahakoti rakenduses, mitte ainult veebiprofiilis või LinkedInis? Kui ei, katab v2.0 sind.
• Kas ma ehitan väljaandjatevahelist usaldusinfrastruktuuri, kus URL-põhisest hostitud kinnitamisest tõeliselt ei piisa? Kui ei, katab v2.0 sind.

Kui vastasid kolm korda „ei,” ei ole sa v2.0 väljastades 2026. aastal maha jäänud — sa vastad spetsifikatsiooniga ökosüsteemile, mis seda tegelikult tarbib. Vaata küsimus uuesti üle siis, kui konkreetne partner või vastavusnõue küsib v3.0-t nimeliselt, mitte üldise tunde põhjal, et „v3 on uuem.”

Rohkem selle kohta, kuidas märgi kinnitamise andmed peavad vastu vanematele, mittestandardsetele tunnistusformaatidele, vaata Blockchain Certificates vs Open Badges, mis süveneb kinnitamise ja ülekantavuse kompromissidesse teisest nurgast.

---

Valmis oma esimest kinnitatavat tunnistust väljastama? Alusta tasuta badges.ninjas — visuaalne disainer, avalik kinnitusleht, PDF-tunnistus, Open Badge v2.0 väljund. Krediitkaarti pole vaja.