Open Badge v2 vs v3 paaiškinta: kurią specifikaciją naudoti šiandien?

Jei 2026 m. kuriate kredencijavimo programą, šis klausimas iškils per pirmą tyrimo valandą: ar išduoti Open Badge v2.0, ar naujesnę v3.0 versiją? Sąžiningas atsakymas yra „tai priklauso nuo to, kas turės skaityti jūsų kredencialus” — bet tai nelabai nuramina, jei sprendimą turite priimti iki penktadienio. Taigi, panagrinėkime, kas iš tikrųjų pasikeitė tarp šių dviejų specifikacijų, kas šiandien ką palaiko ir kurią versiją dauguma išdavėjų turėtų naudoti jau dabar.

Kas iš tikrųjų yra Open Badge v2.0

Open Badge v2.0 yra 1EdTech (anksčiau – IMS Global) specifikacija, kuri nuo 2017 m. yra skaitmeninio kredencijavimo pagrindas. Ji sukurta remiantis JSON-LD ir sudaryta iš trijų susietų objektų:

• IssuerOrg — kas išdavė kredencialą (pavadinimas, URL, el. paštas, logotipas)
• BadgeClass — pats kredencialo tipas (pavadinimas, aprašymas, kriterijai, vaizdas)
• Assertion — konkretus apdovanojimas konkrečiam gavėjui (gavėjo tapatybė, issuedOn data, įrodymai, patikrinimo metodas)

Gavėjo Assertion nurodo į BadgeClass, o šis – atgal į IssuerOrg. Patikrinimas vyksta vienu iš dviejų būdų: hosted (tikrintojas iš stabilaus URL gauna gyvą Assertion JSON ir pasitiki domenu) arba signed (Assertion turi JWS parašą, kurį tikrintojas patikrina pagal išdavėjo paskelbtą viešąjį raktą). Dauguma platformų, įskaitant badges.ninja, pagal numatytuosius nustatymus naudoja hosted patikrinimą, o signed siūlo kaip pasirinkimą, nes hosted paprasčiau įgyvendinti ir žmogui lengviau greitai patikrinti.

Štai supaprastintas v2.0 Assertion pavyzdys — tokį atsakymą gautumėte iš GET /awards/{id} užklausos:

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

Būtent dėl šios struktūros v2.0 tapo faktiniu standartu: ją pakankamai paprasta įgyvendinti per popietę, ir būtent tokios struktūros tikisi beveik kiekvienas ženklelių duomenų vartotojas.

Hosted ir signed patikrinimas v2.0 versijoje

Verta suprasti šiuos du patikrinimo režimus pačioje v2.0 versijoje, nes žmonės dažnai sutapatina teiginius „v2.0 yra mažiau saugi nei v3.0” ir „hosted patikrinimas yra mažiau saugus nei signed”. Tai nėra ta pati ašis.

• Hosted — verification.type reikšmė yra "hosted", o Assertion id yra gyvas URL. Tikrintojas gauna šį URL ir patikrina, ar atsakymas sutampa; pasitikėjimas grindžiamas domeno kontrole (pvz., tik badges.ninja gali publikuoti adresu badges.ninja/certify-badge/award/...). Tai naudoja dauguma vartotojams skirtų patikrinimo puslapių, nes žmogus tiesiog gali paspausti nuorodą.
• Signed — verification.type reikšmė yra "signed", o Assertion turi (arba nurodo) JWS parašą, apimantį duomenis. Tikrintojas gauna išdavėjo viešąjį raktą ir patikrina parašą nepriklausomai nuo to, ar koks nors URL yra pasiekiamas. Tai savo dvasia artimiau v3.0 modeliui, tik be DID sluoksnio.

Minimalus signed patikrinimas Node aplinkoje atrodo taip:

import { jwtVerify, importJWK } from 'jose';

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

Jei jūsų programai svarbu, kad kredencialai išliktų patikrinami net tada, kai jūsų API laikinai neveikia dėl priežiūros darbų, signed v2.0 suteikia didžiąją dalį v3.0 ilgaamžiškumo naudos, nereikalaujant diegti DID.

Kas keičiasi su Open Badge v3.0

Open Badge v3.0 yra perrašymas, sukurtas ant W3C Verifiable Credentials (VC) Data Model pagrindo, o ne palaipsninis v2.0 JSON-LD struktūros atnaujinimas. Praktikoje svarbiausi skirtumai:

• Kriptografinis pasirašymas pagal numatytuosius nustatymus. Kiekvienas v3.0 kredencialas yra pasirašytas VC — nėra jokio atsarginio varianto „hosted, pasitikėk URL”. Patikrinimas visada yra matematinis, o ne pagrįstas domenu.
• Išdavėjo tapatybė pagrįsta DID. Vietoj IssuerOrg objekto su URL ir el. paštu, išdavėjas identifikuojamas decentralizuotu identifikatoriumi (DID), kuris nukreipia į viešojo rakto dokumentą.
• Suderinamumas su Comprehensive Learner Record (CLR) 2.0. v3.0 buvo sukurta taip, kad būtų suderinama su CLR, todėl vienas kredencialas gali apimti tiek pasiekimo duomenis, tiek struktūrizuotą pažymių išrašo informaciją, kurios tikisi CLR vartotojai (kompetencijos, vertinimo rezultatai, semestro/kurso kontekstas).
• Suderinamumas su skaitmeninėmis piniginėmis. Kadangi v3.0 kredencialai yra standartiniai W3C VC, juos galima laikyti tapatybės piniginėse taip pat, kaip vairuotojo pažymėjimą ar vakcinacijos pažymėjimą — o ne tik rodyti tinklalapyje.

Trumpai tariant: v2.0 atsako į klausimą „ar žmogus arba paprastas skriptas gali patikrinti šį kredencialą”, o v3.0 atsako į klausimą „ar šis kredencialas gali sąveikauti su platesne patikrinamų kredencialų ekosistema — piniginėmis, DID, oficialiais mokymosi įrašais”.

Palyginimas greta

Kodėl esama infrastruktūra vis dar veikia su v2.0

Būtent šis aspektas daugumai programų nulemia sprendimą: vietos, kuriose jūsų gavėjai iš tikrųjų nori matyti savo kredencialus, vis dar tikisi v2.0. LinkedIn „Add to Profile” funkcija, Credly, Badgr ir didžioji dauguma kandidatų atrankos sistemų (ATS) integracijų nuskaito v2.0 Assertion/BadgeClass struktūrą. Jei jūsų tikslas yra „gavėjai gali paskelbti tai LinkedIn, o darbuotojų atrankos specialistai gali paspausti ir patikrinti”, v2.0 nėra pasenęs formatas, prie kurio esate pririšti — tai formatas, kuriuo šiandien kalba visa ekosistema.

Būtent šią įtampą iš gavėjo pusės aptarėme straipsnyje LinkedIn Skill Assessments prieš Open Badges — ženklelio vertė didele dalimi priklauso nuo to, kaip lengvai jis integruojasi į vietas, kur darbuotojų atrankos specialistai ir kolegos jau ir taip žiūri, o šiandien tai daugiausia v2.0 formos infrastruktūra.

Kada v3.0 iš tikrųjų svarbi

v3.0 nėra tik mada — ji sprendžia realias problemas konkrečioms programoms:

• Universitetai ir išdavėjai, kuriems privaloma CLR. Jei kredencialus išduodate kartu su oficialia pažymių išrašo sistema arba valstybinė/regioninė švietimo institucija reikalauja CLR 2.0 suderinamos išvesties, v3.0 integruotas suderinamumas apsaugo jus nuo poreikio prisegti CLR laukus prie v2.0 Assertion.
• Programos, orientuotos į saugojimą skaitmeninėse piniginėse. Jei jūsų gavėjams reikia laikyti kredencialą piniginės programėlėje, o ne tik rodyti jį tinklalapyje, ten natyviai veiks tik W3C VC (t. y. v3.0).
• Kredencialų mainai tarp skirtingų išdavėjų, grindžiami DID pasitikėjimu. Jei kuriate ar prisijungiate prie tinklo, kuriame išdavėjo tapatybė turi būti kriptografiškai perkeliama, o ne grįsta principu „pasitikėk šiuo URL”, DID yra tinkamas pagrindinis elementas.

Nė vienas iš šių atvejų nėra tipiškas mokymo programai, bootcamp’ui ar profesinio tobulėjimo išdavėjui 2026 m. Tai būdinga institucijoms, kurioms taikomi atitikties ar sąveikumo reikalavimai, konkrečiai įvardijantys CLR arba W3C VC.

Supaprastintas v3.0 kredencialas parodo, kaip skiriasi visas „vokas”, net jei pagrindiniai pasiekimo duomenys konceptualiai atitinka tą patį apdovanojimą:

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

Atkreipkite dėmesį, kad issuer laukas yra DID, o ne URL, ir visame dokumente vietoj verification nuorodos yra proof blokas. Tai ir yra minėtas DID sprendimo + VC pasirašymo įrankių rinkinys — realus inžinerinis darbas, kuris nueina veltui, jei tolesnėje grandinėje niekas jo dar realiai nenaudoja.

Klaidingi įsitikinimai, kuriuos verta išsklaidyti

• „v3.0 yra saugesnė.” Nebūtinai — tiek signed v2.0, tiek v3.0 remiasi kriptografiniu patikrinimu. v3.0 pranašumas yra standartizuota tapatybė (DID) ir piniginių sąveikumas, o ne saugumo patobulinimas, palyginti su signed v2.0.
• „v2.0 yra pasenusi.” Tai netiesa. 1EdTech palaiko abi specifikacijas, o v2.0 tebėra versija, į kurią orientuojasi platformos ir integracijos, kurias išdavėjai realiai naudoja kasdien.
• „Visai programai reikia pasirinkti vieną variantą.” Nereikia. Niekas netrukdo išdavėjui bendram naudojimui publikuoti v2.0, o konkrečiai partnerio integracijai, kuriai to reikia, papildomai pridėti v3.0 išvestį — pagrindiniai apdovanojimo duomenys nekinta, keičiasi tik jų pateikimo forma.

Perėjimo kelias (ir kodėl jums nereikia rinktis amžinai)

Praktiškiausias žingsnis beveik kiekvienam išdavėjui: jau dabar naudoti v2.0, o v3.0 traktuoti kaip papildymą, o ne pakaitalą, kai to konkrečiai pareikalauja tolesnės grandinės vartotojas. Kelios priežastys, kodėl tai puikiai veikia:

1. Jūsų BadgeClass ir Assertion ID nereikia keisti, kai vėliau pridėsite v3.0 palaikymą — jūs tiesiog pridedate antrą, kitokios formos to paties pagrindinio apdovanojimo pateikimą, o ne migruojate esamų gavėjų kredencialus.
2. Tikrintojai, kurie supranta tik v2.0, ir toliau veikia lygiai taip pat kaip anksčiau.
3. Išvengiate DID infrastruktūros ir VC pasirašymo procesų kūrimo dar prieš atsirandant konkrečiam reikalavimui, kuriam jų reikia.

Tai ta pati logika, kurią patys taikome badges.ninja viduje: kiekvienas apdovanojimas išeina kaip v2.0 Open Badge — JSON-LD, hosted patikrinimas stabiliu /certify-badge/award/{guid} URL, LinkedIn „Add to Profile” paruošta iš karto — nes tai apima didžiąją daugumą to, ko iš tikrųjų prašoma iš išdavėjų. Jei jūsų programai vėliau prireiks v3.0/CLR išvesties konkrečiam instituciniam partneriui, tai bus apibrėžtos apimties papildymas prie jau veikiančio v2.0 proceso, o ne perrašymas nuo nulio.

Tokia seka taip pat apsaugo jus nuo subtilesnės rizikos: įsipareigojimo DID infrastruktūrai dar nežinant, kokio DID metodo iš tikrųjų tikisi jūsų partneriai. VC ekosistema dar nesusitarė dėl vieno DID metodo — praktikoje sutinkami did:web, did:key ir su registrais (ledger) susieti metodai, o netinkamo metodo pasirinkimas bandomajam partneriui reiškia, kad vėliau teks iš naujo perdaryti išdavėjo tapatybės darbą. Laukdami konkrečiai įvardyto reikalavimo, sužinosite, kokio metodo jums iš tikrųjų reikia, dar prieš pradedant ką nors kurti.

Greitas savęs patikrinimas savo programai

Prieš skirdami inžinerinio darbo laiko v3.0, užduokite sau šiuos tris klausimus:

• Ar bent vienas mano kredencialų vartotojas — darbdavio ATS, licencijavimo institucija, partnerinė organizacija — aiškiai reikalauja CLR 2.0 arba W3C VC išvesties? Jei ne, v2.0 jums tinka.
• Ar mano gavėjams reikia laikyti šį kredencialą skaitmeninės piniginės programėlėje, o ne tik interneto profilyje ar LinkedIn? Jei ne, v2.0 jums tinka.
• Ar aš kuriu tarp išdavėjų veikiančią pasitikėjimo infrastruktūrą, kurioje URL pagrįstas hosted patikrinimas iš tikrųjų nepakankamas? Jei ne, v2.0 jums tinka.

Jei tris kartus atsakėte „ne”, naudodami v2.0 2026 m. jūs neatsiliekate — jūs tiesiog derinate specifikaciją prie ekosistemos, kuri ją iš tikrųjų naudoja. Prie šio klausimo grįžkite tada, kai konkretus partneris ar atitikties reikalavimas vardu paprašys v3.0, o ne remdamiesi bendru jausmu, kad „v3 yra naujesnė”.

Daugiau apie tai, kaip ženklelių patikrinimo duomenys atrodo, palyginti su senesniais, nestandartiniais kredencialų formatais, skaitykite straipsnyje Blockchain sertifikatai prieš Open Badges, kuriame patikrinimo ir perkeliamumo kompromisai nagrinėjami iš kito kampo.

---

Pasiruošę išduoti savo pirmąjį patikrinamą kredencialą? Pradėkite nemokamai badges.ninja — vizualus dizaineris, vieša patikrinimo puslapis, PDF sertifikatas, Open Badge v2.0 išvestis. Kredito kortelė nereikalinga.