Open Badges: den åbne standard bag verificerbare beviser

Standarden deler et bevis op i tre dele, og opdelingen er klogere, end den umiddelbart ser ud. Issuer beskriver, hvem der udsteder: navn, website, kontakt. BadgeClass beskriver, hvad der tildeles: bevisets titel, beskrivelse, kriterier, billede. Assertion er til sidst den enkelte tildeling: netop denne person har fået denne BadgeClass på denne dato.

Dermed skal beskrivelsen af en certifikattype kun findes én gang, uanset om I tildeler den til 20 eller 2.000 mennesker. Sådan ser en rigtig Assertion fra vores system ud, kun token'et er forkortet:

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

To detaljer er et ekstra blik værd. Feltet badge er kun en adresse: dér ligger BadgeClass, som igen peger på Issuer, og sådan arbejder et verifikationsværktøj sig gennem hele kæden. Og som recipient står her adressen på certifikatsiden; en e-mailadresse, heller ikke en hashet, optræder ingen steder. Det offentlige dokument klarer sig dermed uden direkte kontaktoplysninger. Personens navn står på den linkede certifikatside, dér hvor personen selv skrev det ind ved afhentningen.

Specifikationen kender to måder at gøre en Assertion verificerbar på. Ved signerede badges bærer dokumentet en kryptografisk signatur fra udstederen, så det beviser sig selv, men det kræver til gengæld nøglehåndtering hos udstederen. Ved hostede badges gælder en enklere regel: en Assertion er ægte, så længe den kan hentes på sin egen id-adresse hos udstederen. At verificere betyder så bare: hent URL'en og sammenlign.

Den hostede fremgangsmåde har en undervurderet fordel: den rene tilbagekaldelse. Trækker udstederen et bevis tilbage, svarer den samme adresse fra det øjeblik med HTTP-status 410 og et kort dokument med linjen „revoked: true“. Et tilbagekaldt certifikat forsvinder altså ikke bare, det siger aktivt fra. Sådan gør vi det også hos OneClickBadge, for eksempel når et certifikat ved en fejl er blevet udstedt to gange.

En detalje ved standarden er næsten poetisk: „baking“. Badge-grafikken, som regel en PNG, får sin Assertion sammen med verifikationsadressen lagt direkte ind i billedfilen, teknisk som en iTXt-tekstblok med nøgleordet openbadges. Billedet ser bagefter helt ens ud, men bærer sin verifikationssti i sig: trækker man filen ind i et verifikationsværktøj, lander man ved beviset, uanset hvor mange downloads og chats billedet har været igennem.

Rækkefølgen er stadig vigtig: kun den hostede Assertion kan bevise noget. Et billede kan kopieres og ændres frit, mens svaret på bevisadressen kun udstederen har kontrol over.

Her rydder vi op i den mest udbredte misforståelse, der spøger i mange artikler: LinkedIn læser ikke Open Badge-metadata. Der er ingen badge-import, ingen automatisk kontrol, intet særligt symbol for verificerede badges. Det, LinkedIn har, er profilafsnittet „Licenser og certifikater“ med felter til navn, udstedende organisation og en URL. Dermed er intet certificeret eller anerkendt af LinkedIn.

Standarden er derfor ikke ubrugelig for LinkedIn, tværtimod: bevisadressen hører hjemme i URL-feltet. Klikker man på „Vis bevis“ i profilen, lander man på certifikatsiden, som den verificerbare Assertion ligger bag. Selve indtastningen kan gøres klar til modtagerne med ét klik, med formularfelterne udfyldt på forhånd. Hvordan det ser ud fra deltagernes side, viser guiden til at tilføje beviset i profilen.

At implementere standarden selv betaler sig for de færreste arrangører: I ville skulle bruge permanent tilgængelige endpoints til Issuer, BadgeClass og hver enkelt Assertion, dertil logik til tilbagekaldelse og et baget billede. Til events, webinarer og kurser findes det færdigt: hos OneClickBadge designer I et deltagerbevis, og hvert udstedt eksemplar får automatisk sin hostede Assertion, tilbagekaldelses-mekanismen og en PDF med billede oveni.

Fordelingen til mange deltagere sker uden at uploade en liste, via et selvbetjeningslink, som I deler efter eventet. Hvorfor det netop ved beviser også er en beslutning om databeskyttelse, står på siden Certifikater til mange deltagere.

Version 3.0 flytter standarden over på W3C Verifiable Credentials, en model med kryptografiske signaturer og mere kontrol hos modtageren. Til økosystemer på universiteter og langtidsholdbare uddannelsesbeviser er det den rigtige retning. Til brugsscenariet eventdeltagelse er 2.0 i den hostede form det pragmatiske valg i dag: alle gængse verifikationsværktøjer forstår det, tilbagekaldelsen virker, og ingen skal håndtere wallets eller nøgler. Derfor satser vi på 2.0 hostet og holder roligt øje med 3.0.