Open Badge v2 vs v3 förklarat: Vilken spec ska du använda idag?

Om du sätter upp ett program för digitala meriter 2026 stöter du på den här frågan redan under den första timmens research: ska du utfärda Open Badge v2.0 eller det nyare v3.0? Det ärliga svaret är ”det beror på vem som ska läsa dina meriter” — men det är inte särskilt tillfredsställande om du är den som måste bestämma sig till fredag. Så låt oss gå igenom vad som faktiskt skiljer de två specifikationerna åt, vem som stödjer vad idag, och vilken de flesta utfärdare bör satsa på just nu.

Vad Open Badge v2.0 faktiskt är

Open Badge v2.0 är specifikationen från 1EdTech (tidigare IMS Global) som har varit ryggraden i digital meritering sedan 2017. Den bygger på JSON-LD och är strukturerad kring tre länkade objekt:

• IssuerOrg — vem som utfärdade meriten (namn, URL, e-post, logotyp)
• BadgeClass — själva meritstypen (namn, beskrivning, kriterier, bild)
• Assertion — den specifika tilldelningen till en specifik mottagare (mottagarens identitet, issuedOn-datum, bevis, verifieringsmetod)

En mottagares Assertion pekar på en BadgeClass, som i sin tur pekar tillbaka på en IssuerOrg. Verifiering sker på ett av två sätt: hosted (verifieraren hämtar den levande Assertion-JSON:en från en stabil URL och litar på domänen) eller signed (Assertion bär en JWS-signatur som verifieraren kontrollerar mot utfärdarens publicerade publika nyckel). De flesta plattformar, inklusive badges.ninja, använder hosted-verifiering som standard med signed som alternativ, eftersom hosted är enklare att implementera och lättare för en människa att snabbkontrollera.

Här är en beskuren v2.0 Assertion, den typ av svar du skulle få tillbaka från ett GET /awards/{id}-anrop:

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

Den strukturen är anledningen till att v2.0 har blivit de facto-standarden: den är tillräckligt enkel för att implementera på en eftermiddag, och det är vad nästan alla konsumenter av märkesdata förväntar sig att se.

Hosted kontra signed-verifiering i v2.0

Det är värt att förstå de två verifieringslägena inom v2.0 självt, eftersom folk ofta blandar ihop ”v2.0 är mindre säkert än v3.0” med ”hosted-verifiering är mindre säkert än signed”. Det är inte samma axel.

• Hosted — verification.type är "hosted", och Assertion:ens id är en levande URL. En verifierare hämtar den URL:en och kontrollerar att svaret stämmer; förtroendet kommer från att kontrollera domänen (t.ex. att endast badges.ninja kan publicera till badges.ninja/certify-badge/award/...). Det är detta de flesta konsumentvända verifieringssidor använder, eftersom en människa helt enkelt kan klicka på länken.
• Signed — verification.type är "signed", och Assertion:en bär (eller refererar till) en JWS-signatur över payloaden. En verifierare löser upp utfärdarens publika nyckel och kontrollerar signaturen oberoende av om någon URL går att nå. Det ligger närmare v3.0:s modell i andemening, bara utan DID-lagret.

En minimal signed-verifieringskontroll i Node ser ut så här:

import { jwtVerify, importJWK } from 'jose';

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

Om ditt program bryr sig om att meriterna förblir verifierbara även efter att ditt API går offline för underhåll, ger signed v2.0 dig större delen av v3.0:s hållbarhetsfördel utan att du behöver införa DID:er.

Vad Open Badge v3.0 förändrar

Open Badge v3.0 är en omskrivning ovanpå W3C Verifiable Credentials (VC) Data Model, inte en stegvis uppdatering av v2.0:s JSON-LD-form. Skillnaderna som spelar roll i praktiken:

• Kryptografisk signering som standard. Varje v3.0-merit är en signerad VC — det finns ingen ”hosted, lita på URL:en”-reservlösning. Verifiering är alltid matematisk, inte domänbaserad.
• DID-baserad utfärdaridentitet. Istället för ett IssuerOrg-objekt med en URL och e-post identifieras utfärdaren av en Decentralized Identifier (DID), som pekar mot ett publikt nyckeldokument.
• Anpassning till Comprehensive Learner Record (CLR) 2.0. v3.0 utformades för att samverka med CLR, så en enda merit kan bära både prestationsdata och den typ av strukturerad transkriptdetalj som CLR-konsumenter förväntar sig (kompetenser, bedömningsresultat, termins-/kurskontext).
• Kompatibilitet med digitala plånböcker. Eftersom v3.0-meriter är vanliga W3C VC:er kan de förvaras i identitetsplånböcker på samma sätt som ett körkort eller ett vaccinationsintyg — inte bara visas på en webbsida.

Kort sagt: v2.0 svarar på ”kan en människa eller ett enkelt skript verifiera den här meriten”, och v3.0 svarar på ”kan den här meriten samverka med det bredare ekosystemet för verifierbara meriter — plånböcker, DID:er, formella studieregister”.

Jämförelse sida vid sida

Varför den installerade basen fortfarande kör på v2.0

Det här är det som avgör beslutet för de flesta program: platserna där dina mottagare faktiskt vill att deras meriter ska synas förväntar sig fortfarande v2.0. LinkedIns Add to Profile-flöde, Credly, Badgr och de allra flesta integrationer med rekryteringssystem (ATS) tolkar v2.0:s Assertion/BadgeClass-form. Om ditt mål är att ”mottagare ska kunna posta det här på LinkedIn och rekryterare ska kunna klicka sig vidare för att verifiera det”, är v2.0 inte ett föråldrat format du sitter fast med — det är formatet ekosystemet faktiskt talar just nu.

Vi täckte precis den här spänningen från mottagarens sida i LinkedIn Skill Assessments vs Open Badges — värdet av ett digitalt märke är till stor del en funktion av hur enkelt det kopplar in i de platser rekryterare och kollegor redan tittar på, och idag är det till övervägande del v2.0-formad infrastruktur.

När v3.0 faktiskt spelar roll

v3.0 är inte hype — det löser verkliga problem för specifika program:

• Universitet och utfärdare med CLR-krav. Om du utfärdar parallellt med ett formellt transkriptsystem, eller om en delstatlig/regional utbildningsmyndighet kräver CLR 2.0-kompatibel utdata, sparar v3.0:s inbyggda anpassning dig från att behöva bulta fast CLR-fält på en v2.0 Assertion.
• Program som siktar på lagring i digital plånbok. Om dina mottagare behöver förvara meriten i en plånboksapp istället för att bara visa den på en webbsida, är det bara en W3C VC (det vill säga v3.0) som fungerar nativt där.
• Meritutbyte mellan utfärdare med DID-baserat förtroende. Om du bygger eller ansluter till ett nätverk där utfärdaridentiteten behöver vara kryptografiskt portabel istället för ”lita på den här URL:en”, är DID:er rätt primitiv.

Inget av det där är vanliga fall för ett utbildningsprogram, en bootcamp eller en utfärdare av kompetensutveckling 2026. De är vanliga för institutioner med efterlevnads- eller interoperabilitetskrav som specifikt namnger CLR eller W3C VC:er.

En beskuren v3.0-merit visar hur olika kuvertet ser ut, även när den underliggande prestationsdatan konceptuellt är samma utmärkelse:

{
  "@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ägg märke till att issuer-fältet är en DID, inte en URL, och att hela dokumentet bär ett proof-block istället för en verification-pekare. Det är DID-uppslaget + VC-signeringsverktygen som nämndes ovan — verkligt utvecklingsarbete, och arbete som är bortkastat om ingenting i nästa led faktiskt konsumerar det ännu.

Vanliga missuppfattningar värda att reda ut

• ”v3.0 är säkrare.” Inte nödvändigtvis — både signed v2.0 och v3.0 bygger på kryptografisk verifiering. v3.0:s fördel är standardiserad identitet (DID:er) och plånboksinteroperabilitet, inte en säkerhetsuppgradering jämfört med signed v2.0.
• ”v2.0 är avvecklat.” Det är det inte. 1EdTech underhåller båda specifikationerna, och v2.0 förblir den version som de plattformar och integrationer som utfärdare faktiskt använder dagligen refererar till.
• ”Du måste välja en för hela programmet.” Det måste du inte. Inget hindrar en utfärdare från att publicera v2.0 för allmänt bruk och lägga till v3.0-utdata för en specifik partnerintegration som kräver det — den underliggande tilldelningsdatan ändras inte, bara representationen.

Migreringsvägen (och varför du inte behöver välja för evigt)

Det praktiska draget för nästan alla utfärdare: leverera v2.0 nu, och behandla v3.0 som ett tillägg, inte en ersättning, när en specifik konsument i nästa led kräver det. Några skäl till varför det här fungerar smidigt:

1. Dina BadgeClass- och Assertion-ID:n behöver inte ändras när du lägger till v3.0-stöd senare — du lägger till en andra, annorlunda formad representation av samma underliggande utmärkelse, du migrerar inte befintliga mottagares meriter.
2. Verifierare som bara förstår v2.0 fortsätter fungera precis som förut.
3. Du slipper bygga DID-infrastruktur och VC-signeringspipelines innan du har ett konkret krav som behöver dem.

Det är samma logik vi använder internt på badges.ninja: varje tilldelning går ut som ett v2.0 Open Badge — JSON-LD, hosted-verifiering på en stabil /certify-badge/award/{guid}-URL, redo för LinkedIn Add to Profile direkt ur lådan — eftersom det täcker den överväldigande majoriteten av vad utfärdare faktiskt blir ombedda att producera. Om ditt program senare behöver v3.0/CLR-utdata för en specifik institutionell partner är det ett avgränsat tillägg ovanpå en fungerande v2.0-pipeline, inte en omskrivning.

Den ordningsföljden skyddar dig också mot en subtilare risk: att binda dig till DID-infrastruktur innan du vet vilken DID-metod dina partners faktiskt förväntar sig. VC-ekosystemet har inte enats om en enda DID-metod — did:web, did:key och ledger-förankrade metoder dyker alla upp i verkligheten, och att välja fel för en pilotpartner innebär att du måste göra om utfärdaridentitetsarbetet senare. Att vänta på ett namngivet krav innebär att du hinner ta reda på vilken metod du faktiskt behöver innan du bygger något.

En snabb magkänslokontroll för ditt eget program

Ställ dessa tre frågor innan du lägger utvecklingstid på v3.0:

• Kräver någon konsument av mina meriter — ett arbetsgivar-ATS, en licensieringsnämnd, en partnerinstitution — uttryckligen CLR 2.0- eller W3C VC-utdata? Om nej täcker v2.0 dina behov.
• Behöver mina mottagare förvara den här meriten i en digital plånboksapp, inte bara en webbprofil eller LinkedIn? Om nej täcker v2.0 dina behov.
• Bygger jag förtroendeinfrastruktur mellan utfärdare där URL-baserad hosted-verifiering genuint inte räcker till? Om nej täcker v2.0 dina behov.

Om du svarade ”nej” tre gånger ligger du inte efter genom att leverera v2.0 under 2026 — du anpassar specifikationen till det ekosystem som faktiskt konsumerar den. Ta upp frågan igen när ett specifikt partner- eller efterlevnadskrav uttryckligen efterfrågar v3.0 vid namn, inte utifrån en allmän känsla av att ”v3 är nyare”.

Vill du läsa mer om hur märkesverifieringsdata står sig mot äldre, icke-standardiserade meritsformat, se Blockchain Certificates vs Open Badges, som gräver djupare i avvägningarna kring verifiering och portabilitet ur en annan vinkel.

---

Redo att utfärda din första verifierbara merit? Kom igång gratis på badges.ninja — visuell designer, publik verifieringssida, PDF-certifikat, Open Badge v2.0-utdata. Inget kreditkort krävs.