Open Badges: de open standaard achter controleerbare bewijzen

De standaard splitst een bewijs in drie delen, en die scheiding is slimmer dan ze op het eerste gezicht lijkt. De Issuer beschrijft wie uitgeeft: naam, website, contact. De BadgeClass beschrijft wat wordt uitgereikt: titel van het bewijs, beschrijving, criteria, beeld. De Assertion ten slotte is de afzonderlijke uitreiking: deze ene persoon heeft deze BadgeClass op deze datum gekregen.

Daardoor hoeft de beschrijving van een certificaattype maar één keer te bestaan, of jullie het nu aan 20 of 2.000 mensen uitreiken. Zo ziet een echte assertion uit ons systeem eruit, alleen de token is ingekort:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

Twee details verdienen een tweede blik. Het veld badge is alleen een adres: daar staat de BadgeClass, die op zijn beurt naar de Issuer verwijst, zo werkt een controletool zich door de hele keten. En als recipient staat hier het adres van de certificaatpagina; een e-mailadres, ook een gehasht adres, komt nergens voor. Het openbare document heeft zo geen directe contactgegevens nodig. De naam van de persoon staat op de gelinkte certificaatpagina, daar waar die hem bij het ophalen zelf heeft ingevuld.

De specificatie kent twee manieren om een assertion controleerbaar te maken. Bij gesigneerde badges draagt het document een cryptografische handtekening van de uitgever, het bewijst zichzelf dus, maar dat vraagt sleutelbeheer aan de kant van de uitgever. Bij gehoste badges geldt een eenvoudiger regel: de assertion is echt zolang die op zijn eigen id-adres bij de uitgever op te vragen is. Controleren betekent dan simpelweg: de URL opvragen en vergelijken.

De gehoste aanpak heeft een onderschat voordeel: de nette intrekking. Trekt de uitgever een bewijs terug, dan antwoordt hetzelfde adres vanaf dat moment met de HTTP-status 410 en een kort document met de regel “revoked: true”. Een ingetrokken certificaat verdwijnt dus niet zomaar, het geeft actief aan dat het niet meer geldig is. Zo doen we het ook bij OneClickBadge, bijvoorbeeld wanneer een certificaat per ongeluk dubbel is uitgegeven.

Eén detail van de standaard is bijna poëtisch: het “baking”. De badge-afbeelding, meestal een PNG, krijgt zijn assertion samen met het controle-adres rechtstreeks in het beeldbestand ingebed, technisch als iTXt-tekstblok met het sleutelwoord openbadges. Het beeld ziet er daarna precies hetzelfde uit, maar draagt zijn controlepad in zich: wie het bestand in een controletool sleept, komt bij de assertion uit, hoeveel downloads en chats het beeld ook heeft doorlopen.

De rangorde blijft belangrijk: bewijzen kan alleen de gehoste assertion. Een beeld laat zich naar believen kopiëren en veranderen, het antwoord op het bewijsadres beheert alleen de uitgever.

Hier ruimen we het meest voorkomende misverstand op dat door veel artikelen spookt: LinkedIn leest geen Open Badge-metadata. Er is daar geen badge-import, geen automatische controle, geen speciaal symbool voor geverifieerde badges. Wat LinkedIn wél heeft, is het profielonderdeel “Licenties en certificaten” met velden voor een naam, een uitgevende organisatie en een URL. Door LinkedIn gecertificeerd of erkend is daarmee niets.

Nutteloos voor LinkedIn is de standaard daarom niet, integendeel: in het URL-veld hoort het bewijsadres. Wie in het profiel op “Bewijs weergeven” klikt, komt op de certificaatpagina, waarachter de controleerbare assertion staat. De vermelding zelf laat zich voor ontvangers met één klik voorbereiden, met al ingevulde formuliervelden. Hoe dit er vanuit de deelnemers gezien uitziet, laat de gids voor het toevoegen aan je profiel zien.

De standaard zelf implementeren loont voor de minste organisatoren: jullie zouden permanent bereikbare endpoints nodig hebben voor de Issuer, de BadgeClass en elke afzonderlijke Assertion, plus intrekkingslogica en een gebakken beeld. Voor events, webinars en trainingen kan het kant-en-klaar: bij OneClickBadge ontwerpen jullie een deelnamecertificaat, en elk uitgegeven exemplaar krijgt automatisch zijn gehoste assertion, het intrekkingsmechanisme en de PDF met beeld erbij.

De verdeling onder veel deelnemers verloopt daarbij zonder lijst-upload, via een zelfophaal-link die jullie na het event delen. Waarom dat juist bij het bewijs-thema ook een privacykeuze is, staat op de pagina Certificaten voor veel deelnemers.

Versie 3.0 zet de standaard over op W3C Verifiable Credentials, een model met cryptografische handtekeningen en meer controle bij de ontvanger. Voor onderwijs-ecosystemen en langlevende opleidingsbewijzen is dat de juiste richting. Voor het gebruiksscenario evenementdeelname is 2.0 in de gehoste vorm vandaag de pragmatische stand van zaken: elke gangbare controletool begrijpt het, de intrekking werkt, en niemand hoeft wallets of sleutels te beheren. Daarom zetten wij in op 2.0 gehost en houden we 3.0 rustig in de gaten.