Open Badge v2 vs v3 skaidrojums: kuru specifikāciju izmantot šodien?

Ja 2026. gadā veidojat kvalifikāciju apliecinošu programmu, jau pirmajā izpētes stundā uzdursieties šim jautājumam: vai izdot Open Badge v2.0 vai jaunāko v3.0? Godīga atbilde ir „tas atkarīgs no tā, kam jāspēj nolasīt jūsu izdotās nozīmes” — taču tas nav apmierinoši, ja tieši jums šis lēmums jāpieņem līdz piektdienai. Tāpēc apskatīsim, kas patiesībā ir mainījies starp abām specifikācijām, kas ko atbalsta šodien, un kuru no tām lielākajai daļai izdevēju vajadzētu izmantot jau tagad.

Kas patiesībā ir Open Badge v2.0

Open Badge v2.0 ir 1EdTech (agrāk IMS Global) specifikācija, kas kopš 2017. gada ir bijusi digitālās kvalifikācijas apliecināšanas mugurkauls. Tā balstīta uz JSON-LD un strukturēta ap trim savstarpēji saistītiem objektiem:

• IssuerOrg — kas izdevis kvalifikāciju (nosaukums, URL, e-pasts, logotips)
• BadgeClass — pati kvalifikācijas veida definīcija (nosaukums, apraksts, kritēriji, attēls)
• Assertion — konkrētais piešķīrums konkrētam saņēmējam (saņēmēja identitāte, izdošanas datums, pierādījumi, verifikācijas metode)

Saņēmēja Assertion norāda uz BadgeClass, kas savukārt norāda atpakaļ uz IssuerOrg. Verifikācija notiek vienā no diviem veidiem: hostēta (verificētājs ielādē dzīvo Assertion JSON no stabila URL un uzticas domēnam) vai parakstīta (Assertion satur JWS parakstu, ko verificētājs pārbauda pret izdevēja publicēto publisko atslēgu). Lielākā daļa platformu, tostarp badges.ninja, pēc noklusējuma izmanto hostēto verifikāciju ar parakstīto kā papildu iespēju, jo hostētā ir vienkāršāk ieviešama un cilvēkam ir vieglāk pārbaudāma.

Šeit ir saīsināta v2.0 Assertion — tāda, kādu saņemtu, izsaucot 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" }
}

Šī struktūra ir iemesls, kāpēc v2.0 ir kļuvusi par de facto standartu: to var ieviest pēcpusdienas laikā, un tieši šādu formātu sagaida gandrīz ikviens, kas patērē nozīmju datus.

Hostēta vai parakstīta verifikācija v2.0

Ir vērts izprast šos divus verifikācijas režīmus pašā v2.0 iekšienē, jo cilvēki bieži sajauc apgalvojumu „v2.0 ir mazāk droša nekā v3.0” ar „hostētā verifikācija ir mazāk droša nekā parakstītā”. Tā nav viena un tā pati ass.

• Hostēta — verification.type ir "hosted", un Assertion id ir dzīvs URL. Verificētājs ielādē šo URL un pārbauda, vai atbilde sakrīt; uzticēšanās balstās uz domēna kontroli (piemēram, tikai badges.ninja var publicēt zem badges.ninja/certify-badge/award/...). Tieši šo variantu izmanto vairums patērētājiem paredzēto verifikācijas lapu, jo cilvēks vienkārši var noklikšķināt uz saites.
• Parakstīta — verification.type ir "signed", un Assertion satur (vai norāda uz) JWS parakstu par lietderīgo kravu. Verificētājs iegūst izdevēja publisko atslēgu un pārbauda parakstu neatkarīgi no tā, vai kāds URL vispār ir sasniedzams. Tas pēc būtības ir tuvāk v3.0 modelim, tikai bez DID slāņa.

Minimāla parakstītas verifikācijas pārbaude Node vidē izskatās šādi:

import { jwtVerify, importJWK } from 'jose';

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

Ja jūsu programmai ir svarīgi, lai kvalifikācijas paliktu verificējamas arī tad, kad jūsu API ir bezsaistē tehniskās apkopes dēļ, parakstīta v2.0 sniedz lielāko daļu no v3.0 noturības priekšrocībām, neieviešot DID.

Kas mainās ar Open Badge v3.0

Open Badge v3.0 ir pilnīga pārrakstīšana, kas balstīta uz W3C Verifiable Credentials (VC) Data Model, nevis pakāpenisks uzlabojums v2.0 JSON-LD struktūrai. Praksē nozīmīgākās atšķirības:

• Kriptogrāfisks paraksts pēc noklusējuma. Katra v3.0 kvalifikācija ir parakstīta VC — nav nekādas „hostētas, uzticies URL” rezerves iespējas. Verifikācija vienmēr ir matemātiska, nevis balstīta uz domēnu.
• Uz DID balstīta izdevēja identitāte. Tā vietā, lai izmantotu IssuerOrg objektu ar URL un e-pastu, izdevējs tiek identificēts ar decentralizētu identifikatoru (DID), kas atrisinās uz publiskās atslēgas dokumentu.
• Saskaņotība ar Comprehensive Learner Record (CLR) 2.0. v3.0 ir izstrādāta tā, lai sadarbotos ar CLR, tāpēc viena kvalifikācija var saturēt gan sasnieguma datus, gan tāda veida strukturētu izraksta detalizāciju, kādu sagaida CLR patērētāji (kompetences, novērtējuma rezultāti, semestra/kursa konteksts).
• Saderība ar digitālajām maciņu lietotnēm. Tā kā v3.0 kvalifikācijas ir standarta W3C VC, tās var glabāt identitātes maciņos tāpat kā autovadītāja apliecību vai vakcinācijas apliecinājumu — nevis tikai attēlot tīmekļa lapā.

Īsāk sakot: v2.0 atbild uz jautājumu „vai cilvēks vai vienkāršs skripts var pārbaudīt šo kvalifikāciju”, bet v3.0 atbild uz jautājumu „vai šī kvalifikācija var mijiedarboties ar plašāku pārbaudāmo kvalifikāciju ekosistēmu — maciņiem, DID, formāliem izglītojamo ierakstiem”.

Salīdzinājums blakus

Kāpēc esošā infrastruktūra joprojām darbojas uz v2.0

Šī ir tā daļa, kas lielākajai daļai programmu nosver lēmumu: vietas, kur jūsu saņēmēji patiešām vēlas redzēt savas kvalifikācijas, joprojām sagaida v2.0. LinkedIn Add to Profile plūsma, Credly, Badgr un lielākā daļa pretendentu izsekošanas sistēmu (ATS) integrāciju analizē tieši v2.0 Assertion/BadgeClass struktūru. Ja jūsu mērķis ir „saņēmēji var ievietot šo LinkedIn profilā, un darbā pieņemšanas speciālisti var noklikšķināt, lai to pārbaudītu”, v2.0 nav novecojis formāts, kurā esat iesprostots — tas ir formāts, kurā ekosistēma šobrīd „runā”.

Mēs šo pašu saspīlējumu no saņēmēja skatpunkta aplūkojām rakstā LinkedIn Skill Assessments pretstatā Open Badges — nozīmes vērtība lielā mērā ir atkarīga no tā, cik viegli tā iekļaujas vietās, kur darbā pieņemšanas speciālisti un kolēģi jau tāpat skatās, un šodien tā ir pārsvarā v2.0 formāta infrastruktūra.

Kad v3.0 patiešām ir svarīga

v3.0 nav tikai reklāmas troksnis — tā risina reālas problēmas konkrētām programmām:

• Universitātēm un izdevējiem ar CLR pienākumiem. Ja izdodat kvalifikācijas līdztekus formālai izraksta sistēmai vai valsts/reģionālā izglītības iestāde pieprasa CLR 2.0 saderīgu izvadi, v3.0 iebūvētā saskaņotība ietaupa jums nepieciešamību piestiprināt CLR laukus v2.0 Assertion.
• Programmām, kas paredzētas glabāšanai digitālajā maciņā. Ja jūsu saņēmējiem kvalifikācija jāglabā maciņa lietotnē, nevis tikai jāattēlo tīmekļa lapā, tur natīvi darbosies tikai W3C VC (proti, v3.0).
• Starpizdevēju kvalifikāciju apmaiņai ar uz DID balstītu uzticēšanos. Ja veidojat vai pievienojaties tīklam, kurā izdevēja identitātei jābūt kriptogrāfiski pārnesamai, nevis balstītai uz „uzticies šim URL”, DID ir pareizais pamatelements.

Neviens no šiem gadījumiem 2026. gadā nav tipisks apmācību programmai, bootcamp’am vai profesionālās pilnveides izdevējam. Tie ir tipiski iestādēm ar atbilstības vai savietojamības prasībām, kas konkrēti nosauc CLR vai W3C VC.

Saīsināta v3.0 kvalifikācija parāda, cik atšķirīgs ir „aploksnes” izskats, pat ja pamatā esošie sasnieguma dati konceptuāli ir tas pats piešķīrums:

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

Pamaniet, ka izdevēja lauks ir DID, nevis URL, un viss dokuments satur proof bloku, nevis verification norādi. Tas ir iepriekš minētais DID atrisināšanas un VC parakstīšanas rīku kopums — reāls inženiertehnisks darbs, un darbs, kas ir veltīgs, ja neviens vēl to patiešām nepatērē tālāk pa ķēdi.

Izplatīti maldīgi priekšstati, ko vērts izskaidrot

• „v3.0 ir drošāka.” Ne vienmēr — gan parakstīta v2.0, gan v3.0 balstās uz kriptogrāfisku verifikāciju. v3.0 priekšrocība ir standartizēta identitāte (DID) un maciņa savietojamība, nevis drošības uzlabojums salīdzinājumā ar parakstītu v2.0.
• „v2.0 ir novecojusi.” Tā nav. 1EdTech uztur abas specifikācijas, un v2.0 joprojām ir versija, uz kuru atsaucas platformas un integrācijas, ko izdevēji ikdienā faktiski izmanto.
• „Visai programmai jāizvēlas viena no tām.” Tā nav jādara. Nekas neliedz izdevējam publicēt v2.0 vispārējai lietošanai un pievienot v3.0 izvadi konkrētai partnera integrācijai, kurai tā nepieciešama — pamatā esošie piešķīruma dati nemainās, mainās tikai to attēlojums.

Migrācijas ceļš (un kāpēc jums nav uz visiem laikiem jāizvēlas viena)

Praktiskais risinājums gandrīz katram izdevējam: izdodiet v2.0 jau tagad un uztveriet v3.0 kā papildinājumu, nevis aizstājēju, kad to konkrēti pieprasa kāds patērētājs tālāk pa ķēdi. Vairāki iemesli, kāpēc tas darbojas gludi:

1. Jūsu BadgeClass un Assertion ID nav jāmaina, kad vēlāk pievienojat v3.0 atbalstu — jūs pievienojat otru, atšķirīgi veidotu, tās pašas pamatā esošās kvalifikācijas attēlojumu, nevis migrējat esošo saņēmēju kvalifikācijas.
2. Verificētāji, kas saprot tikai v2.0, turpina darboties tieši tāpat kā iepriekš.
3. Jūs izvairāties no DID infrastruktūras un VC parakstīšanas cauruļvadu veidošanas, pirms jums ir konkrēta prasība, kurai tie nepieciešami.

Tieši šo pašu loģiku mēs iekšēji izmantojam badges.ninja platformā: katrs piešķīrums tiek izdots kā v2.0 Open Badge — JSON-LD, hostēta verifikācija stabilā /certify-badge/award/{guid} URL, LinkedIn Add to Profile gatavība uzreiz no kastes — jo tas nosedz milzīgu vairākumu no tā, ko izdevējiem faktiski lūdz nodrošināt. Ja jūsu programmai vēlāk būs nepieciešama v3.0/CLR izvade konkrētam institucionālam partnerim, tas ir ierobežots papildinājums strādājošam v2.0 cauruļvadam, nevis pārrakstīšana no jauna.

Šāda secība pasargā jūs arī no smalkāka riska: apņemšanās veidot DID infrastruktūru, pirms zināt, kuru DID metodi jūsu partneri faktiski sagaida. VC ekosistēma nav vienojusies par vienu DID metodi — savvaļā sastopamas gan did:web, gan did:key, gan uz virsgrāmatu balstītas metodes, un nepareizas metodes izvēle pilotprogrammas partnerim nozīmē, ka izdevēja identitātes darbs vēlāk jāpārtaisa. Gaidīšana uz nosauktu prasību nozīmē, ka uzzināsiet, kura metode jums patiešām nepieciešama, pirms sākat kaut ko būvēt.

Ātra pašpārbaude jūsu programmai

Uzdodiet šos trīs jautājumus, pirms veltāt inženiertehnisko laiku v3.0:

• Vai kāds no jūsu kvalifikāciju patērētājiem — darba devēja ATS, licencēšanas padome, partneriestāde — skaidri pieprasa CLR 2.0 vai W3C VC izvadi? Ja nē, v2.0 jums pietiek.
• Vai jūsu saņēmējiem šī kvalifikācija jāglabā digitālā maciņa lietotnē, nevis tikai tīmekļa profilā vai LinkedIn? Ja nē, v2.0 jums pietiek.
• Vai veidojat starpizdevēju uzticēšanās infrastruktūru, kurā uz URL balstīta hostētā verifikācija patiešām nav pietiekama? Ja nē, v2.0 jums pietiek.

Ja atbildējāt „nē” visiem trim jautājumiem, jūs neatpaliekat, izdodot v2.0 2026. gadā — jūs pielāgojat specifikāciju ekosistēmai, kas to faktiski patērē. Atgriezieties pie šī jautājuma tad, kad konkrēts partneris vai atbilstības prasība nosauks v3.0 vārdā, nevis vadoties pēc vispārīgas sajūtas, ka „v3 ir jaunāka”.

Vairāk par to, kā nozīmju verifikācijas dati izturas salīdzinājumā ar vecākiem, nestandartizētiem kvalifikācijas formātiem, lasiet rakstā Blockchain sertifikāti pretstatā Open Badges, kas no cita skatpunkta iedziļinās verifikācijas un pārnesamības kompromisos.

---

Gatavi izdot savu pirmo verificējamo kvalifikāciju? Sāciet bez maksas badges.ninja platformā — vizuālais dizaineris, publiska verifikācijas lapa, PDF sertifikāts, Open Badge v2.0 izvade. Bankas karte nav nepieciešama.