Open Badge v2 vs v3 forklaret: Hvilken specifikation bør du bruge i dag?

Hvis du er ved at sætte et badge-program op i 2026, støder du på dette spørgsmål inden for den første time af din research: skal du udstede Open Badge v2.0 eller det nyere v3.0? Det ærlige svar er “det afhænger af, hvem der skal læse dine badges” — men det er ikke særlig tilfredsstillende, hvis det er dig, der skal beslutte det inden fredag. Så lad os gennemgå, hvad der faktisk ændrede sig mellem de to specifikationer, hvem der understøtter hvad i dag, og hvilken de fleste udstedere bør bruge lige nu.

Hvad Open Badge v2.0 egentlig er

Open Badge v2.0 er 1EdTechs (tidligere IMS Global) specifikation, der har været rygraden i digital badge-udstedelse siden 2017. Den er bygget på JSON-LD og struktureret omkring tre sammenkædede objekter:

• IssuerOrg — hvem der udstedte badget (navn, URL, e-mail, logo)
• BadgeClass — selve badge-typen (navn, beskrivelse, kriterier, billede)
• Assertion — den specifikke tildeling til en specifik modtager (modtagers identitet, issuedOn-dato, dokumentation, verificeringsmetode)

En modtagers Assertion peger på en BadgeClass, som peger tilbage til en IssuerOrg. Verificering foregår på en af to måder: hosted (verifikatoren henter den live Assertion-JSON fra en stabil URL og stoler på domænet) eller signed (Assertion’en bærer en JWS-signatur, som verifikatoren tjekker mod udstederens offentliggjorte offentlige nøgle). De fleste platforme, inklusive badges.ninja, bruger som standard hosted verificering med signed som en mulighed, fordi hosted er enklere at implementere og lettere for et menneske at stikprøvekontrollere.

Her er en beskåret v2.0 Assertion, den slags du ville få tilbage fra et GET /awards/{id}-kald:

{
  "@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 struktur er grunden til, at v2.0 er blevet de facto-standarden: den er enkel nok til at implementere på en eftermiddag, og det er, hvad næsten alle forbrugere af badge-data forventer at se.

Hosted vs. signed verificering i v2.0

Det er værd at forstå de to verificeringstilstande i v2.0 selv, fordi folk ofte sammenblander “v2.0 er mindre sikkert end v3.0” med “hosted verificering er mindre sikkert end signed.” Det er ikke den samme akse.

• Hosted — verification.type er "hosted", og Assertion’ens id er en live URL. En verifikator henter denne URL og tjekker, at svaret matcher; tillid kommer fra at kontrollere domænet (f.eks. kan kun badges.ninja publicere til badges.ninja/certify-badge/award/...). Dette er, hvad de fleste forbrugervendte verificeringssider bruger, fordi et menneske bare kan klikke på linket.
• Signed — verification.type er "signed", og Assertion’en bærer (eller refererer til) en JWS-signatur over indholdet. En verifikator finder udstederens offentlige nøgle og tjekker signaturen uafhængigt af, om nogen URL er tilgængelig. Dette ligger tættere på v3.0’s model i ånd, bare uden DID-laget.

Et minimalt signed-verificeringstjek i Node ser sådan ud:

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 dit program bekymrer sig om, at badges forbliver verificerbare, selv efter dit API går offline til vedligeholdelse, giver signed v2.0 dig det meste af holdbarhedsfordelen ved v3.0 uden at skulle indføre DID’er.

Hvad Open Badge v3.0 ændrer

Open Badge v3.0 er en gennemskrivning oven på W3C Verifiable Credentials (VC) Data Model, ikke en trinvis opdatering af v2.0’s JSON-LD-form. De forskelle, der betyder noget i praksis:

• Kryptografisk signering som standard. Hvert v3.0-badge er en signed VC — der er ingen “hosted, stol på URL’en”-fallback. Verificering er altid matematisk, ikke domænebaseret.
• DID-baseret udsteder-identitet. I stedet for et IssuerOrg-objekt med en URL og e-mail identificeres udstederen ved en Decentralized Identifier (DID), som opløses til et offentligt nøgledokument.
• Alignment med Comprehensive Learner Record (CLR) 2.0. v3.0 er designet til at fungere sammen med CLR, så et enkelt badge kan bære både præstationsdata og den slags strukturerede transskript-detaljer, CLR-forbrugere forventer (kompetencer, vurderingsresultater, term-/kursuskontekst).
• Kompatibilitet med digitale wallets. Fordi v3.0-badges er standard W3C VC’er, kan de opbevares i identitets-wallets på samme måde som et kørekort eller et vaccinationsbevis — ikke bare vises på en webside.

Kort sagt: v2.0 besvarer “kan et menneske eller et simpelt script verificere dette badge,” og v3.0 besvarer “kan dette badge fungere sammen med det bredere verifiable-credentials-økosystem — wallets, DID’er, formelle learner records.”

Side-om-side-sammenligning

Hvorfor den etablerede base stadig kører på v2.0

Dette er den del, der afgør beslutningen for de fleste programmer: de steder, hvor dine modtagere faktisk ønsker, at deres badges skal vises, forventer stadig v2.0. LinkedIns Add to Profile-flow, Credly, Badgr og langt de fleste applicant-tracking-system-integrationer parser v2.0’s Assertion/BadgeClass-form. Hvis dit mål er “modtagere kan poste dette på LinkedIn, og rekrutterere kan klikke igennem for at verificere det,” er v2.0 ikke et forældet format, du sidder fast med — det er det format, økosystemet i øjeblikket taler.

Vi dækkede præcis denne spænding fra modtagerens side i LinkedIn Skill Assessments vs Open Badges — værdien af et badge er i høj grad en funktion af, hvor let det passer ind i de steder, rekrutterere og kolleger allerede kigger, og i dag er det overvejende v2.0-formet infrastruktur.

Hvornår v3.0 faktisk betyder noget

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

• Universiteter og udstedere under CLR-krav. Hvis du udsteder sammen med et formelt transskript-system, eller et statsligt/regionalt uddannelsesorgan kræver CLR 2.0-kompatibelt output, sparer v3.0’s indbyggede alignment dig for at skulle bolte CLR-felter på en v2.0-Assertion.
• Programmer, der sigter mod opbevaring i digitale wallets. Hvis dine modtagere har brug for at opbevare badget i en wallet-app i stedet for blot at vise det på en webside, er det kun en W3C VC (dvs. v3.0), der fungerer native til det.
• Udveksling af badges på tværs af udstedere med DID-baseret tillid. Hvis du bygger eller tilslutter dig et netværk, hvor udsteder-identitet skal være kryptografisk portabel i stedet for “stol på denne URL,” er DID’er det rigtige værktøj.

Ingen af disse er almindelige tilfælde for et trænings- eller bootcamp-program eller en udbyder af professionel udvikling i 2026. De er almindelige for institutioner med compliance- eller interoperabilitetskrav, der specifikt navngiver CLR eller W3C VC’er.

Et beskåret v3.0-badge viser, hvor anderledes kuverten ser ud, selv når den underliggende præstationsdata konceptuelt er den samme tildeling:

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

Læg mærke til, at issuer-feltet er en DID, ikke en URL, og at hele dokumentet bærer en proof-blok i stedet for en verification-pointer. Det er den DID-opløsning + VC-signeringsværktøj, der er nævnt ovenfor — reelt udviklingsarbejde, og arbejde, der er spildt, hvis intet nedstrøms rent faktisk bruger det endnu.

Almindelige misforståelser, der er værd at rydde op i

• “v3.0 er mere sikkert.” Ikke nødvendigvis — både signed v2.0 og v3.0 er afhængige af kryptografisk verificering. v3.0’s fordel er standardiseret identitet (DID’er) og wallet-interoperabilitet, ikke en sikkerhedsopgradering i forhold til signed v2.0.
• “v2.0 er udfaset.” Det er den ikke. 1EdTech vedligeholder begge specifikationer, og v2.0 er fortsat den version, der refereres til af de platforme og integrationer, udstedere faktisk bruger i det daglige.
• “Du skal vælge én for hele programmet.” Det behøver du ikke. Intet forhindrer en udsteder i at publicere v2.0 til generel brug og tilføje v3.0-output til en specifik partnerintegration, der kræver det — den underliggende tildelingsdata ændrer sig ikke, kun repræsentationen.

Migreringsvejen (og hvorfor du ikke behøver vælge for evigt)

Det praktiske træk for stort set alle udstedere: udrul v2.0 nu, og behandl v3.0 som en tilføjelse, ikke en erstatning, når en specifik forbruger nedstrøms kræver det. Et par grunde til, at dette fungerer problemfrit:

1. Dine BadgeClass- og Assertion-ID’er behøver ikke at ændre sig, når du senere tilføjer v3.0-understøttelse — du tilføjer en anden, anderledes formet repræsentation af samme underliggende tildeling, ikke migrerer eksisterende modtageres badges.
2. Verifikatorer, der kun forstår v2.0, fortsætter med at fungere præcis som før.
3. Du undgår at bygge DID-infrastruktur og VC-signeringspipelines, før du har et konkret behov for dem.

Dette er den samme logik, vi bruger internt hos badges.ninja: hvert badge udgives som et v2.0 Open Badge — JSON-LD, hosted verificering på en stabil /certify-badge/award/{guid}-URL, klar til LinkedIn Add to Profile ud af boksen — fordi det dækker langt de fleste af de ting, udstedere rent faktisk bliver bedt om at levere. Hvis dit program senere har brug for v3.0/CLR-output til en specifik institutionel partner, er det en afgrænset tilføjelse oven på en fungerende v2.0-pipeline, ikke en omskrivning.

Denne rækkefølge beskytter dig også mod en mere subtil risiko: at forpligte dig til DID-infrastruktur, før du ved, hvilken DID-metode dine partnere faktisk forventer. VC-økosystemet har ikke samlet sig om én DID-metode — did:web, did:key og ledger-forankrede metoder dukker alle op i praksis, og at vælge den forkerte til en pilotpartner betyder, at du skal gøre udsteder-identitetsarbejdet om senere. Ved at vente på et navngivet krav finder du ud af, hvilken metode du faktisk har brug for, før du bygger noget.

Et hurtigt tjek til dit eget program

Stil disse tre spørgsmål, før du bruger udviklingstid på v3.0:

• Kræver nogen forbruger af mine badges — en arbejdsgivers ATS, et licensorgan, en partnerinstitution — eksplicit CLR 2.0- eller W3C VC-output? Hvis nej, dækker v2.0 dig.
• Har mine modtagere brug for at opbevare dette badge i en digital wallet-app, ikke bare en webprofil eller LinkedIn? Hvis nej, dækker v2.0 dig.
• Bygger du tillidsinfrastruktur på tværs af udstedere, hvor URL-baseret hosted verificering reelt ikke er tilstrækkelig? Hvis nej, dækker v2.0 dig.

Hvis du svarede “nej” tre gange, er du ikke bagud ved at udrulle v2.0 i 2026 — du matcher specifikationen til det økosystem, der faktisk bruger den. Tag spørgsmålet op igen, når en specifik partner eller et compliance-krav beder om v3.0 ved navn, ikke ud fra en generel fornemmelse af, at “v3 er nyere.”

For mere om, hvordan badge-verificeringsdata klarer sig mod ældre, ikke-standardiserede badge-formater, se Blockchain Certificates vs Open Badges, som dykker ned i afvejningerne mellem verificering og portabilitet fra en anden vinkel.

---

Klar til at udstede dit første verificerbare badge? Start gratis på badges.ninja — visuel designer, offentlig verificeringsside, PDF-certifikat, Open Badge v2.0-output. Intet kreditkort påkrævet.