Open Badge v2 vs v3 selitettynä: Kumpaa spesifikaatiota sinun pitäisi käyttää tänään?

Jos olet perustamassa osaamismerkkiohjelmaa vuonna 2026, törmäät tähän kysymykseen jo tutkimuksesi ensimmäisen tunnin aikana: pitäisikö sinun myöntää Open Badge v2.0 vai uudempi v3.0? Rehellinen vastaus on ”se riippuu siitä, kenen pitää lukea merkkisi” — mutta se ei ole kovin tyydyttävä, jos sinun pitää päättää asia perjantaihin mennessä. Käydään siis läpi, mikä kahden spesifikaation välillä oikeasti muuttui, kuka tukee mitäkin tänään, ja kumpaa useimpien myöntäjien kannattaisi käyttää juuri nyt.

Mitä Open Badge v2.0 oikeastaan on

Open Badge v2.0 on 1EdTechin (aiemmin IMS Global) spesifikaatio, joka on ollut digitaalisen osaamismerkkien myöntämisen selkäranka vuodesta 2017 lähtien. Se perustuu JSON-LD:hen ja rakentuu kolmen toisiinsa linkitetyn objektin ympärille:

• IssuerOrg — kuka myönsi merkin (nimi, URL, sähköposti, logo)
• BadgeClass — itse merkkityyppi (nimi, kuvaus, kriteerit, kuva)
• Assertion — tietylle vastaanottajalle annettu tietty myöntö (vastaanottajan identiteetti, issuedOn-päivämäärä, todisteet, varmennusmenetelmä)

Vastaanottajan Assertion viittaa BadgeClassiin, joka viittaa takaisin IssuerOrgiin. Varmennus tapahtuu kahdella tavalla: hosted (varmentaja hakee elävän Assertion-JSON:n vakaasta URL-osoitteesta ja luottaa verkkotunnukseen) tai signed (Assertion sisältää JWS-allekirjoituksen, jonka varmentaja tarkistaa myöntäjän julkaisemaa julkista avainta vasten). Useimmat alustat, badges.ninja mukaan lukien, käyttävät oletuksena hosted-varmennusta ja tarjoavat signed-vaihtoehdon, koska hosted on yksinkertaisempi toteuttaa ja helpompi ihmisen pistokoetarkistaa.

Tässä on lyhennetty v2.0-Assertion, sellainen kuin saisit vastauksena GET /awards/{id}-kutsuun:

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

Tämä rakenne on syy siihen, miksi v2.0:sta on tullut de facto -standardi: se on tarpeeksi yksinkertainen toteuttaa iltapäivässä, ja se on juuri sitä, mitä lähes jokainen merkkidatan kuluttaja odottaa näkevänsä.

Hosted- ja signed-varmennus v2.0:ssa

Kannattaa ymmärtää v2.0:n kaksi varmennustapaa erikseen, koska ihmiset sekoittavat usein väitteen ”v2.0 on vähemmän turvallinen kuin v3.0” väitteeseen ”hosted-varmennus on vähemmän turvallinen kuin signed”. Ne eivät ole sama asia.

• Hosted — verification.type on "hosted", ja Assertionin id on elävä URL-osoite. Varmentaja hakee tämän URL-osoitteen ja tarkistaa, että vastaus täsmää; luottamus perustuu verkkotunnuksen hallintaan (esim. vain badges.ninja voi julkaista osoitteeseen badges.ninja/certify-badge/award/...). Tätä käyttävät useimmat kuluttajille suunnatut varmennussivut, koska ihminen voi vain klikata linkkiä.
• Signed — verification.type on "signed", ja Assertion sisältää (tai viittaa) JWS-allekirjoituksen datasta. Varmentaja hakee myöntäjän julkisen avaimen ja tarkistaa allekirjoituksen riippumatta siitä, onko mikään URL-osoite tavoitettavissa. Tämä muistuttaa hengeltään enemmän v3.0:n mallia, vain ilman DID-kerrosta.

Minimaalinen signed-varmennuksen tarkistus Node.js:ssä näyttää tältä:

import { jwtVerify, importJWK } from 'jose';

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

Jos ohjelmassasi on tärkeää, että merkit pysyvät varmennettavissa myös sen jälkeen, kun API:si menee huoltokatkolle, signed v2.0 antaa sinulle suurimman osan v3.0:n pitkäikäisyyshyödystä ilman DID-ratkaisujen käyttöönottoa.

Mitä Open Badge v3.0 muuttaa

Open Badge v3.0 on kirjoitettu uudelleen W3C Verifiable Credentials (VC) Data Model -mallin päälle — se ei ole asteittainen päivitys v2.0:n JSON-LD-muotoon. Käytännössä merkitsevät erot:

• Kryptografinen allekirjoitus oletuksena. Jokainen v3.0-todiste on signed VC — ei ole ”hosted, luota URL-osoitteeseen” -varavaihtoehtoa. Varmennus on aina matemaattista, ei verkkotunnuspohjaista.
• DID-pohjainen myöntäjän identiteetti. URL-osoitteella ja sähköpostilla varustetun IssuerOrg-objektin sijaan myöntäjä tunnistetaan hajautetulla tunnisteella (DID), joka ratkeaa julkisen avaimen dokumentiksi.
• Yhteensopivuus Comprehensive Learner Recordin (CLR) 2.0:n kanssa. v3.0 suunniteltiin toimimaan yhdessä CLR:n kanssa, joten yksi todiste voi sisältää sekä saavutustietoja että sellaisia rakenteisia opintosuoritustietoja, joita CLR:n kuluttajat odottavat (kompetenssit, arviointitulokset, jakso-/kurssikonteksti).
• Yhteensopivuus digitaalisten lompakoiden kanssa. Koska v3.0-todisteet ovat standardin mukaisia W3C VC:itä, niitä voi säilyttää identiteettilompakoissa samalla tavalla kuin ajokorttia tai rokotustodistusta — ei vain näyttää verkkosivulla.

Lyhyesti: v2.0 vastaa kysymykseen ”voiko ihminen tai yksinkertainen skripti varmentaa tämän todisteen”, ja v3.0 vastaa kysymykseen ”voiko tämä todiste toimia yhteen laajemman verifiable credentials -ekosysteemin kanssa — lompakot, DID:t, muodolliset learner recordit”.

Rinnakkaisvertailu

Miksi vakiintunut käyttäjäkunta pyörii yhä v2.0:lla

Tämä on se osa, joka kallistaa päätöksen useimpien ohjelmien kohdalla: paikat, joissa vastaanottajasi oikeasti haluavat todisteidensa näkyvän, odottavat yhä v2.0:aa. LinkedInin Add to Profile -toiminto, Credly, Badgr ja valtaosa applicant tracking -järjestelmien integraatioista jäsentävät v2.0:n Assertion/BadgeClass-muotoa. Jos tavoitteesi on ”vastaanottajat voivat julkaista tämän LinkedInissä, ja rekrytoijat voivat klikata läpi varmentaakseen sen”, v2.0 ei ole vanhentunut muoto, johon olet jumissa — se on muoto, jota ekosysteemi tällä hetkellä puhuu.

Käsittelimme juuri tätä jännitettä vastaanottajan näkökulmasta artikkelissa LinkedIn Skill Assessments vs Open Badges — merkin arvo on pitkälti sitä, kuinka helposti se sopii paikkoihin, joita rekrytoijat ja kollegat jo katsovat, ja tänään se tarkoittaa valtaosin v2.0-muotoista infrastruktuuria.

Milloin v3.0 oikeasti on tärkeä

v3.0 ei ole hypeä — se ratkaisee todellisia ongelmia tietyille ohjelmille:

• Yliopistot ja myöntäjät, joita CLR-vaatimukset koskevat. Jos myönnät todisteita muodollisen opintosuoritusjärjestelmän rinnalla, tai osavaltion/alueellinen koulutuselin vaatii CLR 2.0 -yhteensopivaa tulostetta, v3.0:n sisäänrakennettu yhteensopivuus säästää sinut CLR-kenttien liittämiseltä v2.0-Assertioniin jälkikäteen.
• Ohjelmat, jotka tähtäävät digitaaliseen lompakkosäilytykseen. Jos vastaanottajiesi täytyy säilyttää todiste lompakkosovelluksessa pelkän verkkosivulla näyttämisen sijaan, vain W3C VC (eli v3.0) toimii siihen natiivisti.
• Myöntäjien välinen todisteiden vaihto DID-pohjaisella luottamuksella. Jos rakennat tai liityt verkostoon, jossa myöntäjän identiteetin täytyy olla kryptografisesti siirrettävissä sen sijaan, että ”luotetaan tähän URL-osoitteeseen”, DID:t ovat oikea työkalu.

Mikään näistä ei ole yleinen tapaus koulutusohjelmalle, bootcampille tai ammatillisen kehityksen myöntäjälle vuonna 2026. Ne ovat yleisiä instituutioille, joilla on compliance- tai yhteentoimivuusvaatimuksia, jotka nimenomaisesti mainitsevat CLR:n tai W3C VC:t.

Lyhennetty v3.0-todiste näyttää, kuinka erilainen kuori on, vaikka taustalla oleva saavutustieto on käsitteellisesti sama myöntö:

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

Huomaa, että issuer-kenttä on DID, ei URL-osoite, ja koko dokumentti sisältää proof-lohkon verification-osoittimen sijaan. Se on edellä mainittua DID-ratkaisua + VC:n allekirjoitustyökaluja — todellista kehitystyötä, ja työtä, joka menee hukkaan, jos mikään alavirran järjestelmä ei vielä oikeasti kuluta sitä.

Yleisiä väärinkäsityksiä, jotka kannattaa oikaista

• ”v3.0 on turvallisempi.” Ei välttämättä — sekä signed v2.0 että v3.0 nojaavat kryptografiseen varmennukseen. v3.0:n etu on standardoitu identiteetti (DID:t) ja lompakko-yhteentoimivuus, ei turvallisuuspäivitys signed v2.0:aan verrattuna.
• ”v2.0 on vanhentunut.” Ei ole. 1EdTech ylläpitää molempia spesifikaatioita, ja v2.0 on yhä versio, johon alustat ja integraatiot, joita myöntäjät oikeasti käyttävät päivittäin, viittaavat.
• ”Sinun täytyy valita yksi koko ohjelmalle.” Ei tarvitse. Mikään ei estä myöntäjää julkaisemasta v2.0:aa yleiskäyttöön ja lisäämästä v3.0-tulostetta tiettyä kumppani-integraatiota varten, joka sitä vaatii — taustalla oleva myöntödata ei muutu, vain esitystapa.

Migraatiopolku (ja miksi sinun ei tarvitse valita ikuisiksi ajoiksi)

Käytännöllinen ratkaisu lähes kaikille myöntäjille: julkaise v2.0 nyt ja kohtele v3.0:aa lisäyksenä, ei korvaajana, kun tietty alavirran kuluttaja sitä vaatii. Muutama syy sille, miksi tämä toimii mutkattomasti:

1. BadgeClass- ja Assertion-tunnuksesi eivät tarvitse muuttua, kun lisäät v3.0-tuen myöhemmin — lisäät toisen, eri tavalla muotoillun esityksen samasta taustalla olevasta myönnöstä, et migroi olemassa olevien vastaanottajien todisteita.
2. Varmentajat, jotka ymmärtävät vain v2.0:aa, jatkavat toimimista täsmälleen kuten ennenkin.
3. Vältät DID-infrastruktuurin ja VC:n allekirjoitusputkien rakentamisen ennen kuin sinulla on konkreettinen tarve, joka niitä edellyttää.

Tämä on sama logiikka, jota käytämme sisäisesti badges.ninjassa: jokainen myöntö lähtee liikkeelle v2.0 Open Badgena — JSON-LD, hosted-varmennus vakaassa /certify-badge/award/{guid}-osoitteessa, LinkedIn Add to Profile -valmiudella suoraan laatikosta — koska se kattaa valtaosan siitä, mitä myöntäjiltä oikeasti pyydetään. Jos ohjelmasi tarvitsee myöhemmin v3.0/CLR-tulostetta tiettyä institutionaalista kumppania varten, se on rajattu lisäys toimivan v2.0-putken päälle, ei uudelleenkirjoitus.

Tämä järjestys suojaa sinua myös hienovaraisemmalta riskiltä: DID-infrastruktuuriin sitoutumiselta ennen kuin tiedät, mitä DID-metodia kumppanisi oikeasti odottavat. VC-ekosysteemi ei ole vielä yhtenäistynyt yhden DID-metodin ympärille — did:web, did:key ja ledgeriin ankkuroidut metodit näkyvät kaikki käytännössä, ja väärän valitseminen pilottikumppanille tarkoittaa myöntäjän identiteettityön tekemistä uudelleen myöhemmin. Nimetyn vaatimuksen odottaminen tarkoittaa, että selvität, mitä metodia oikeasti tarvitset, ennen kuin rakennat mitään.

Nopea tarkistuslista omalle ohjelmallesi

Kysy nämä kolme kysymystä ennen kuin käytät kehitysaikaa v3.0:aan:

• Vaatiiko joku todisteideni kuluttaja — työnantajan ATS, lupalautakunta, kumppani-instituutio — nimenomaisesti CLR 2.0- tai W3C VC -tulostetta? Jos ei, v2.0 riittää sinulle.
• Täytyykö vastaanottajieni säilyttää tämä todiste digitaalisessa lompakkosovelluksessa eikä vain verkkoprofiilissa tai LinkedInissä? Jos ei, v2.0 riittää sinulle.
• Rakennatko myöntäjien välistä luottamusinfrastruktuuria, jossa URL-pohjainen hosted-varmennus ei aidosti riitä? Jos ei, v2.0 riittää sinulle.

Jos vastasit ”ei” kolme kertaa, et ole jäljessä julkaisemalla v2.0:aa vuonna 2026 — sovitat spesifikaation ekosysteemiin, joka sitä oikeasti kuluttaa. Palaa kysymykseen, kun tietty kumppani tai compliance-vaatimus pyytää v3.0:aa nimeltä, ei sen yleisen tunteen perusteella, että ”v3 on uudempi”.

Lisää siitä, miten merkkien varmennusdata pärjää vanhempia, ei-standardoituja todistusmuotoja vastaan, löydät artikkelista Blockchain Certificates vs Open Badges, joka sukeltaa varmennuksen ja siirrettävyyden kompromisseihin toisesta näkökulmasta.

---

Valmiina myöntämään ensimmäisen varmennettavan todisteesi? Aloita ilmaiseksi badges.ninjassa — visuaalinen suunnittelutyökalu, julkinen varmennussivu, PDF-todistus, Open Badge v2.0 -tuloste. Ei luottokorttia vaadita.