Open Badge v2 vs v3 Uitgelegd: Welke Spec Moet Je Vandaag Gebruiken?

Als je in 2026 een credentialing-programma opzet, loop je binnen het eerste uur onderzoek tegen deze vraag aan: moet je Open Badge v2.0 of het nieuwere v3.0 uitgeven? Het eerlijke antwoord is “het hangt af van wie je credentials moet lezen” — maar dat is niet bevredigend als jij degene bent die voor vrijdag moet beslissen. Laten we daarom doornemen wat er echt veranderd is tussen de twee specs, wie vandaag wat ondersteunt, en welke de meeste uitgevers nu zouden moeten gebruiken.

Wat Open Badge v2.0 werkelijk is

Open Badge v2.0 is de 1EdTech-specificatie (voorheen IMS Global) die sinds 2017 de ruggengraat vormt van digitale credentialing. Het is gebouwd op JSON-LD en gestructureerd rond drie gekoppelde objecten:

• IssuerOrg — wie de credential heeft uitgegeven (naam, URL, e-mail, logo)
• BadgeClass — het type credential zelf (naam, omschrijving, criteria, afbeelding)
• Assertion — de specifieke toekenning aan een specifieke ontvanger (identiteit van de ontvanger, issuedOn-datum, bewijs, verificatiemethode)

De Assertion van een ontvanger verwijst naar een BadgeClass, die op zijn beurt terugverwijst naar een IssuerOrg. Verificatie gebeurt op een van twee manieren: hosted (de verificateur haalt de live Assertion-JSON op van een stabiele URL en vertrouwt op het domein) of signed (de Assertion draagt een JWS-handtekening die de verificateur controleert tegen de gepubliceerde publieke sleutel van de uitgever). De meeste platformen, waaronder badges.ninja, gebruiken standaard hosted-verificatie met signed als optie, omdat hosted eenvoudiger te implementeren is en makkelijker voor een mens om even te controleren.

Hier is een ingekorte v2.0 Assertion, het soort dat je terugkrijgt van een GET /awards/{id}-aanroep:

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

Die structuur is de reden dat v2.0 de facto standaard is geworden: het is eenvoudig genoeg om in een middag te implementeren, en het is wat vrijwel elke afnemer van badge-data verwacht te zien.

Hosted vs signed verificatie in v2.0

Het loont om de twee verificatiemodi binnen v2.0 zelf te begrijpen, want mensen verwarren vaak “v2.0 is minder veilig dan v3.0” met “hosted-verificatie is minder veilig dan signed.” Dat zijn niet dezelfde as.

• Hosted — de verification.type is "hosted", en de id van de Assertion is een live URL. Een verificateur haalt die URL op en controleert of de respons overeenkomt; vertrouwen komt voort uit controle over het domein (alleen badges.ninja kan bijvoorbeeld publiceren naar badges.ninja/certify-badge/award/...). Dit gebruiken de meeste consumentgerichte verificatiepagina’s, omdat een mens simpelweg op de link kan klikken.
• Signed — de verification.type is "signed", en de Assertion draagt (of verwijst naar) een JWS-handtekening over de payload. Een verificateur haalt de publieke sleutel van de uitgever op en controleert de handtekening onafhankelijk van of een URL bereikbaar is. Dit ligt qua geest dichter bij het model van v3.0, alleen zonder de DID-laag.

Een minimale signed-verificatiecheck in Node ziet er zo uit:

import { jwtVerify, importJWK } from 'jose';

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

Als het voor jouw programma belangrijk is dat credentials verifieerbaar blijven ook nadat je API tijdelijk offline is voor onderhoud, geeft signed v2.0 je het grootste deel van het duurzaamheidsvoordeel van v3.0 zonder DID’s te hoeven invoeren.

Wat Open Badge v3.0 verandert

Open Badge v3.0 is een herschrijving bovenop het W3C Verifiable Credentials (VC) Data Model, geen incrementele update van de JSON-LD-vorm van v2.0. De verschillen die er in de praktijk toe doen:

• Cryptografisch ondertekenen als standaard. Elke v3.0-credential is een ondertekende VC — er is geen “hosted, vertrouw de URL”-terugvaloptie. Verificatie is altijd wiskundig, niet domeingebaseerd.
• DID-gebaseerde uitgeversidentiteit. In plaats van een IssuerOrg-object met een URL en e-mailadres wordt de uitgever geïdentificeerd door een Decentralized Identifier (DID), die verwijst naar een document met een publieke sleutel.
• Afstemming op de Comprehensive Learner Record (CLR) 2.0. v3.0 is ontworpen om samen te werken met CLR, zodat één credential zowel prestatiegegevens als het soort gestructureerde transcriptdetail kan bevatten dat CLR-afnemers verwachten (competenties, beoordelingsresultaten, term-/vakcontext).
• Compatibiliteit met digitale wallets. Omdat v3.0-credentials standaard W3C VC’s zijn, kunnen ze net als een rijbewijs of vaccinatiebewijs in identiteitswallets worden bewaard — niet alleen op een webpagina worden weergegeven.

Kort samengevat: v2.0 beantwoordt de vraag “kan een mens of een eenvoudig script deze credential verifiëren,” en v3.0 beantwoordt de vraag “kan deze credential samenwerken met het bredere ecosysteem van verifieerbare credentials — wallets, DID’s, formele leerresultatenregistraties.”

Naast elkaar vergeleken

Waarom de bestaande basis nog op v2.0 draait

Dit is het onderdeel dat de beslissing voor de meeste programma’s doet kantelen: de plekken waar je ontvangers hun credentials daadwerkelijk willen laten zien, verwachten nog steeds v2.0. LinkedIn’s Add to Profile-flow, Credly, Badgr, en de overgrote meerderheid van applicant-tracking-system-integraties verwerken de Assertion/BadgeClass-vorm van v2.0. Als je doel is “ontvangers kunnen dit op LinkedIn plaatsen en recruiters kunnen doorklikken om het te verifiëren,” dan is v2.0 geen verouderd formaat waar je aan vastzit — het is het formaat dat het ecosysteem op dit moment spreekt.

We behandelden precies deze spanning vanuit het perspectief van de ontvanger in LinkedIn Skill Assessments vs Open Badges — de waarde van een badge is grotendeels een functie van hoe makkelijk hij past in de plekken waar recruiters en collega’s al kijken, en dat is vandaag overwegend v2.0-vormgegeven infrastructuur.

Wanneer v3.0 er echt toe doet

v3.0 is geen hype — het lost echte problemen op voor specifieke programma’s:

• Universiteiten en uitgevers onder CLR-verplichtingen. Als je uitgeeft naast een formeel transcriptsysteem, of een overheids-/onderwijsinstantie CLR 2.0-compatibele output vereist, bespaart de ingebouwde afstemming van v3.0 je het geknutsel om CLR-velden aan een v2.0-Assertion vast te plakken.
• Programma’s gericht op opslag in digitale wallets. Als je ontvangers de credential in een wallet-app moeten kunnen bewaren in plaats van hem alleen op een webpagina te tonen, werkt alleen een W3C VC (dus v3.0) daar native.
• Cross-uitgever credential-uitwisseling met DID-gebaseerd vertrouwen. Als je een netwerk bouwt of erbij aansluit waar de identiteit van de uitgever cryptografisch overdraagbaar moet zijn in plaats van “vertrouw deze URL,” zijn DID’s het juiste bouwblok.

Geen van deze zijn gangbare gevallen voor een trainingsprogramma, bootcamp of professioneel-ontwikkelings-uitgever in 2026. Ze komen vooral voor bij instellingen met compliance- of interoperabiliteitseisen die specifiek CLR of W3C VC’s noemen.

Een ingekorte v3.0-credential laat zien hoe anders de envelop eruitziet, zelfs wanneer de onderliggende prestatiegegevens conceptueel dezelfde toekenning betreffen:

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

Merk op dat het issuer-veld een DID is, geen URL, en dat het hele document een proof-blok bevat in plaats van een verification-verwijzing. Dat is de DID-resolutie- en VC-ondertekeningstooling die hierboven genoemd werd — echt engineeringwerk, en werk dat verspild is als er stroomafwaarts nog niets is dat het daadwerkelijk verwerkt.

Veelvoorkomende misvattingen die opheldering verdienen

• “v3.0 is veiliger.” Niet per se — signed v2.0 en v3.0 leunen allebei op cryptografische verificatie. Het voordeel van v3.0 zit in gestandaardiseerde identiteit (DID’s) en wallet-interoperabiliteit, niet in een veiligheidsupgrade ten opzichte van signed v2.0.
• “v2.0 is verouderd/uitgefaseerd.” Dat is het niet. 1EdTech onderhoudt beide specs, en v2.0 blijft de versie waar de platformen en integraties die uitgevers dagelijks gebruiken naar verwijzen.
• “Je moet er één kiezen voor het hele programma.” Dat hoeft niet. Niets weerhoudt een uitgever ervan v2.0 te publiceren voor algemeen gebruik en v3.0-output toe te voegen voor een specifieke partnerintegratie die dat vereist — de onderliggende toekenningsgegevens veranderen niet, alleen de representatie.

Het migratiepad (en waarom je niet voor altijd hoeft te kiezen)

De praktische zet voor bijna elke uitgever: lever nu v2.0, en behandel v3.0 als een toevoeging, geen vervanging, wanneer een specifieke afnemer stroomafwaarts erom vraagt. Een paar redenen waarom dit soepel werkt:

1. Je BadgeClass- en Assertion-ID’s hoeven niet te veranderen wanneer je later v3.0-ondersteuning toevoegt — je voegt een tweede, anders vormgegeven representatie van dezelfde onderliggende toekenning toe, je migreert geen bestaande credentials van ontvangers.
2. Verificateurs die alleen v2.0 begrijpen, blijven precies zo werken als voorheen.
3. Je vermijdt het bouwen van DID-infrastructuur en VC-ondertekeningspijplijnen voordat je een concrete eis hebt die ze nodig heeft.

Dit is dezelfde logica die we intern bij badges.ninja gebruiken: elke toekenning gaat de deur uit als een v2.0 Open Badge — JSON-LD, hosted-verificatie op een stabiele /certify-badge/award/{guid}-URL, kant-en-klaar voor LinkedIn Add to Profile — omdat dat de overgrote meerderheid dekt van wat uitgevers daadwerkelijk gevraagd wordt te produceren. Als jouw programma later v3.0-/CLR-output nodig heeft voor een specifieke institutionele partner, is dat een afgebakende toevoeging bovenop een werkende v2.0-pijplijn, geen herschrijving.

Die volgorde beschermt je ook tegen een subtieler risico: je vastleggen op DID-infrastructuur voordat je weet welke DID-methode je partners daadwerkelijk verwachten. Het VC-ecosysteem is nog niet geconvergeerd op één DID-methode — did:web, did:key, en ledger-verankerde methoden komen allemaal in de praktijk voor, en de verkeerde kiezen voor een pilotpartner betekent dat je het uitgeversidentiteitswerk later moet overdoen. Wachten op een concrete eis betekent dat je eerst weet welke methode je echt nodig hebt voordat je iets bouwt.

Een snelle check voor je eigen programma

Stel jezelf deze drie vragen voordat je engineeringtijd besteedt aan v3.0:

• Vereist een afnemer van mijn credentials — een ATS van een werkgever, een licentiecommissie, een partnerinstelling — expliciet CLR 2.0- of W3C VC-output? Zo niet, dan volstaat v2.0.
• Moeten mijn ontvangers deze credential in een digitale wallet-app kunnen bewaren, en niet alleen op een webprofiel of LinkedIn? Zo niet, dan volstaat v2.0.
• Ben ik cross-uitgever vertrouwensinfrastructuur aan het bouwen waarbij URL-gebaseerde hosted-verificatie werkelijk niet volstaat? Zo niet, dan volstaat v2.0.

Als je drie keer “nee” hebt geantwoord, loop je niet achter door in 2026 v2.0 te leveren — je stemt de spec af op het ecosysteem dat hem daadwerkelijk gebruikt. Kom terug op de vraag zodra een specifieke partner of compliance-eis met naam om v3.0 vraagt, niet op basis van een algemeen gevoel dat “v3 nieuwer is.”

Voor meer over hoe badge-verificatiegegevens zich verhouden tot oudere, niet-gestandaardiseerde credential-formaten, zie Blockchain Certificates vs Open Badges, dat dieper ingaat op de afwegingen rond verificatie en overdraagbaarheid vanuit een andere invalshoek.

---

Klaar om je eerste verifieerbare credential uit te geven? Start gratis bij badges.ninja — visuele ontwerper, publieke verificatiepagina, PDF-certificaat, Open Badge v2.0-output. Geen creditcard nodig.