Open Badge v2 vs v3 forklart: Hvilken spesifikasjon bør du bruke i dag?

Hvis du setter opp et badge-program i 2026, støter du på dette spørsmålet i løpet av den første timen med research: bør du utstede Open Badge v2.0 eller det nyere v3.0? Det ærlige svaret er «det kommer an på hvem som skal lese badgene dine» — men det er ikke særlig tilfredsstillende hvis det er du som må bestemme deg innen fredag. Så la oss gå gjennom hva som faktisk endret seg mellom de to spesifikasjonene, hvem som støtter hva i dag, og hvilken de fleste utstedere bør satse på akkurat nå.

Hva Open Badge v2.0 egentlig er

Open Badge v2.0 er 1EdTechs (tidligere IMS Global) spesifikasjon som har vært ryggraden i digital merke-utstedelse siden 2017. Den er bygget på JSON-LD og strukturert rundt tre sammenkoblede objekter:

• IssuerOrg — hvem som utstedte badget (navn, URL, e-post, logo)
• BadgeClass — selve badgetypen (navn, beskrivelse, kriterier, bilde)
• Assertion — den spesifikke tildelingen til en spesifikk mottaker (mottakers identitet, issuedOn-dato, dokumentasjon, verifiseringsmetode)

En mottakers Assertion peker på en BadgeClass, som peker tilbake til en IssuerOrg. Verifisering skjer på en av to måter: hosted (verifikatoren henter den live Assertion-JSON-en fra en stabil URL og stoler på domenet) eller signed (Assertion-en bærer en JWS-signatur som verifikatoren sjekker mot utstederens publiserte offentlige nøkkel). De fleste plattformer, inkludert badges.ninja, bruker som standard hosted verifisering med signed som et alternativ, fordi hosted er enklere å implementere og lettere for et menneske å stikkprøvekontrollere.

Her er en beskåret v2.0 Assertion, den typen du ville fått tilbake fra et GET /awards/{id}-kall:

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

Denne strukturen er grunnen til at v2.0 har blitt de facto-standarden: den er enkel nok til å implementere på en ettermiddag, og det er det nesten alle forbrukere av badgedata forventer å se.

Hosted vs. signed verifisering i v2.0

Det er verdt å forstå de to verifiseringsmodusene i v2.0 selv, fordi folk ofte blander sammen «v2.0 er mindre sikkert enn v3.0» med «hosted verifisering er mindre sikkert enn signed». Det er ikke samme akse.

• Hosted — verification.type er "hosted", og Assertion-ens id er en live URL. En verifikator henter denne URL-en og sjekker at svaret stemmer; tillit kommer fra å kontrollere domenet (f.eks. kan bare badges.ninja publisere til badges.ninja/certify-badge/award/...). Dette er det de fleste forbrukerrettede verifiseringssider bruker, fordi et menneske bare kan klikke på lenken.
• Signed — verification.type er "signed", og Assertion-en bærer (eller refererer til) en JWS-signatur over innholdet. En verifikator henter utstederens offentlige nøkkel og sjekker signaturen uavhengig av om noen URL er tilgjengelig. Dette ligger nærmere v3.0-modellen i ånden, bare uten DID-laget.

Et minimalt signed-verifiseringssjekk i Node ser slik ut:

import { jwtVerify, importJWK } from 'jose';

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

Hvis programmet ditt bryr seg om at badger forblir verifiserbare selv etter at API-et ditt går offline for vedlikehold, gir signed v2.0 deg det meste av holdbarhetsfordelen til v3.0 uten å måtte innføre DID-er.

Hva Open Badge v3.0 endrer

Open Badge v3.0 er en omskriving oppå W3C Verifiable Credentials (VC) Data Model, ikke en trinnvis oppdatering av v2.0s JSON-LD-form. Forskjellene som betyr noe i praksis:

• Kryptografisk signering som standard. Hvert v3.0-badge er en signed VC — det finnes ingen «hosted, stol på URL-en»-fallback. Verifisering er alltid matematisk, ikke domenebasert.
• DID-basert utsteder-identitet. I stedet for et IssuerOrg-objekt med en URL og e-post identifiseres utstederen med en Decentralized Identifier (DID), som løses opp til et offentlig nøkkeldokument.
• Alignment med Comprehensive Learner Record (CLR) 2.0. v3.0 ble designet for å samhandle med CLR, slik at et enkelt badge kan bære både prestasjonsdata og den typen strukturerte transkript-detaljer CLR-forbrukere forventer (kompetanser, vurderingsresultater, term-/kurskontekst).
• Kompatibilitet med digitale lommebøker. Fordi v3.0-badger er standard W3C VC-er, kan de oppbevares i identitetslommebøker på samme måte som et førerkort eller en vaksinasjonsattest — ikke bare vises på en nettside.

Kort sagt: v2.0 svarer på «kan et menneske eller et enkelt skript verifisere dette badget», og v3.0 svarer på «kan dette badget samhandle med det bredere verifiable-credentials-økosystemet — lommebøker, DID-er, formelle learner records».

Sammenligning side ved side

Hvorfor den etablerte basen fortsatt kjører på v2.0

Dette er delen som avgjør beslutningen for de fleste programmer: stedene hvor mottakerne dine faktisk vil at badgene deres skal vises, forventer fortsatt v2.0. LinkedIns Add to Profile-flyt, Credly, Badgr og de aller fleste applicant-tracking-system-integrasjoner parser v2.0s Assertion/BadgeClass-form. Hvis målet ditt er «mottakere kan poste dette på LinkedIn, og rekrutterere kan klikke seg gjennom for å verifisere det», er v2.0 ikke et utdatert format du sitter fast med — det er formatet økosystemet snakker i dag.

Vi dekket nettopp denne spenningen fra mottakerens side i LinkedIn Skill Assessments vs Open Badges — verdien av et badge er i stor grad en funksjon av hvor lett det passer inn der rekrutterere og kolleger allerede ser etter, og i dag er det overveiende v2.0-formet infrastruktur.

Når v3.0 faktisk betyr noe

v3.0 er ikke hype — det løser reelle problemer for spesifikke programmer:

• Universiteter og utstedere under CLR-krav. Hvis du utsteder sammen med et formelt transkriptsystem, eller et statlig/regionalt utdanningsorgan krever CLR 2.0-kompatibel output, sparer v3.0s innebygde alignment deg for å måtte bolte CLR-felter på en v2.0-Assertion.
• Programmer som sikter mot lagring i digital lommebok. Hvis mottakerne dine trenger å oppbevare badget i en lommebok-app i stedet for bare å vise det på en nettside, er det bare en W3C VC (altså v3.0) som fungerer native til det.
• Utveksling av badger på tvers av utstedere med DID-basert tillit. Hvis du bygger eller blir med i et nettverk der utsteder-identitet må være kryptografisk portabel i stedet for «stol på denne URL-en», er DID-er det riktige verktøyet.

Ingen av disse er vanlige tilfeller for et trenings- eller bootcamp-program eller en tilbyder av kompetanseheving i 2026. De er vanlige for institusjoner med compliance- eller interoperabilitetskrav som spesifikt navngir CLR eller W3C VC-er.

Et beskåret v3.0-badge viser hvor annerledes konvolutten ser ut, selv når den underliggende prestasjonsdataen konseptuelt er den samme tildelingen:

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

Legg merke til at issuer-feltet er en DID, ikke en URL, og at hele dokumentet bærer en proof-blokk i stedet for en verification-peker. Det er DID-oppløsningen + VC-signeringsverktøyet nevnt ovenfor — reelt utviklingsarbeid, og arbeid som er bortkastet hvis ingenting nedstrøms faktisk bruker det ennå.

Vanlige misforståelser verdt å rydde opp i

• «v3.0 er sikrere.» Ikke nødvendigvis — både signed v2.0 og v3.0 er avhengige av kryptografisk verifisering. v3.0s fordel er standardisert identitet (DID-er) og lommebok-interoperabilitet, ikke en sikkerhetsoppgradering i forhold til signed v2.0.
• «v2.0 er utfaset.» Det er det ikke. 1EdTech vedlikeholder begge spesifikasjonene, og v2.0 er fortsatt versjonen som platformene og integrasjonene utstedere faktisk bruker daglig, refererer til.
• «Du må velge én for hele programmet.» Det trenger du ikke. Ingenting hindrer en utsteder i å publisere v2.0 for generell bruk og legge til v3.0-output for en spesifikk partnerintegrasjon som krever det — den underliggende tildelingsdataen endrer seg ikke, bare representasjonen.

Migreringsveien (og hvorfor du ikke trenger å velge for alltid)

Det praktiske grepet for nesten alle utstedere: rull ut v2.0 nå, og behandle v3.0 som et tillegg, ikke en erstatning, når en spesifikk forbruker nedstrøms krever det. Noen grunner til at dette fungerer sømløst:

1. BadgeClass- og Assertion-ID-ene dine trenger ikke endre seg når du legger til v3.0-støtte senere — du legger til en annen, annerledes formet representasjon av samme underliggende tildeling, du migrerer ikke eksisterende mottakeres badger.
2. Verifikatorer som bare forstår v2.0, fortsetter å fungere akkurat som før.
3. Du unngår å bygge DID-infrastruktur og VC-signeringspipeliner før du har et konkret behov som krever dem.

Dette er samme logikk vi bruker internt hos badges.ninja: hvert badge går ut som et v2.0 Open Badge — JSON-LD, hosted verifisering på en stabil /certify-badge/award/{guid}-URL, klar for LinkedIn Add to Profile rett ut av boksen — fordi det dekker det store flertallet av det utstedere faktisk blir bedt om å levere. Hvis programmet ditt senere trenger v3.0/CLR-output for en spesifikk institusjonell partner, er det et avgrenset tillegg oppå en fungerende v2.0-pipeline, ikke en omskriving.

Denne rekkefølgen beskytter deg også mot en mer subtil risiko: å forplikte deg til DID-infrastruktur før du vet hvilken DID-metode partnerne dine faktisk forventer. VC-økosystemet har ikke samlet seg om én DID-metode — did:web, did:key og ledger-forankrede metoder dukker alle opp i praksis, og å velge feil metode for en pilotpartner betyr at du må gjøre om utsteder-identitetsarbeidet senere. Ved å vente på et navngitt krav finner du ut hvilken metode du faktisk trenger, før du bygger noe.

En rask sjekk for ditt eget program

Still disse tre spørsmålene før du bruker utviklingstid på v3.0:

• Krever noen forbruker av badgene mine — en arbeidsgivers ATS, et lisensorgan, en partnerinstitusjon — eksplisitt CLR 2.0- eller W3C VC-output? Hvis nei, dekker v2.0 deg.
• Trenger mottakerne mine å oppbevare dette badget i en digital lommebok-app, ikke bare en webprofil eller LinkedIn? Hvis nei, dekker v2.0 deg.
• Bygger du tillitsinfrastruktur på tvers av utstedere der URL-basert hosted verifisering rett og slett ikke er tilstrekkelig? Hvis nei, dekker v2.0 deg.

Hvis du svarte «nei» tre ganger, er du ikke på etterskudd ved å rulle ut v2.0 i 2026 — du matcher spesifikasjonen til økosystemet som faktisk bruker den. Ta opp spørsmålet igjen når en spesifikk partner eller et compliance-krav ber om v3.0 ved navn, ikke ut fra en generell følelse av at «v3 er nyere».

For mer om hvordan badge-verifiseringsdata holder mål mot eldre, ikke-standardiserte badgeformater, se Blockchain Certificates vs Open Badges, som går i dybden på avveiningene mellom verifisering og portabilitet fra en annen vinkel.

---

Klar til å utstede ditt første verifiserbare badge? Start gratis på badges.ninja — visuell designer, offentlig verifiseringsside, PDF-sertifikat, Open Badge v2.0-output. Ikke kredittkort nødvendig.