Open Badges: den åpne standarden bak verifiserbare bevis
Et Open Badge er et digitalt bevis beskrevet etter en åpen standard: hvem som har fått hva, når og av hvem, lagret som et maskinlesbart dokument på en fast adresse. Hvem som helst kan sjekke den adressen, og ingen leverandør kan låse den inne for seg selv. Denne siden forklarer standarden slik at dere etterpå kan plassere den og ta den i bruk selv. Leter dere etter annonseringsbildet til arrangementet, det som i dagligtale også kalles «badge», så tar siden Lag en LinkedIn-badge for seg det.
Hva et Open Badge er, i ett avsnitt
Et Open Badge er et digitalt bevis på en prestasjon eller deltakelse, beskrevet etter Open Badges-spesifikasjonen. Den ble opprinnelig utviklet av Mozilla og vedlikeholdes i dag av 1EdTech (tidligere IMS Global). Kjernen: alle opplysninger om beviset ligger som et strukturert, offentlig tilgjengelig dokument på en fast URL. Den som vil sjekke beviset, henter rett og slett den URL-en. I versjon 2.0, som er den vi ser på her, består hvert bevis av tre sammenkjedede dokumenter: Issuer, BadgeClass og Assertion.
De tre byggeklossene: Issuer, BadgeClass, Assertion
Standarden deler et bevis i tre deler, og oppdelingen er smartere enn den ser ut ved første øyekast. Issuer beskriver hvem som utsteder: navn, nettside, kontakt. BadgeClass beskriver hva som tildeles: bevisets tittel, beskrivelse, kriterier og bilde. Assertion er selve den enkelte tildelingen: denne ene personen fikk denne BadgeClass på denne datoen.
På den måten trenger beskrivelsen av en bevistype bare finnes én gang, enten dere tildeler den til 20 eller 2 000 personer. Slik ser en ekte assertion fra systemet vårt ut, bare med token-en 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 verdt et nærmere blikk. Feltet badge er bare en adresse: der ligger BadgeClass, som igjen peker på Issuer, og slik jobber et verifiseringsverktøy seg gjennom hele kjeden. Og som recipient står her adressen til bevissiden; en e-postadresse, heller ikke en hashet, dukker aldri opp. Det offentlige dokumentet klarer seg dermed uten direkte kontaktopplysninger. Navnet på personen står på den lenkede bevissiden, der personen selv skrev det inn da beviset ble hentet.
Hosted eller signed: to måter å verifisere på
Spesifikasjonen kjenner to måter å gjøre en assertion verifiserbar på. Ved signerte badger bærer dokumentet en kryptografisk signatur fra utstederen, så det beviser seg selv, men det krever nøkkelhåndtering hos utstederen. Ved hostede badger gjelder en enklere regel: assertion-en er ekte så lenge den kan hentes på sin egen id-adresse hos utstederen. Å verifisere betyr da rett og slett å hente URL-en og sammenligne.
Den hostede metoden har en undervurdert fordel: den rene tilbakekallingen. Trekker utstederen et bevis tilbake, svarer den samme adressen fra da av med HTTP-status 410 og et kort dokument med linjen «revoked: true». Et tilbakekalt bevis blir altså ikke bare taust, det sier aktivt fra om at det ikke lenger er gyldig. Slik gjør vi det også hos OneClickBadge, for eksempel når et bevis ved en feil ble utstedt to ganger.
Bildet bærer beviset på ryggen
En detalj ved standarden er nesten poetisk: «baking». Badge-grafikken, som regel en PNG, får sin assertion sammen med verifiseringsadressen lagt rett inn i bildefilen, teknisk som en iTXt-tekstblokk med nøkkelordet openbadges. Bildet ser nøyaktig likt ut etterpå, men bærer verifiseringsstien i seg: drar dere filen inn i et verifiseringsverktøy, havner dere på assertion-en, uansett hvor mange nedlastinger og chatter bildet har vandret gjennom.
Rekkefølgen betyr fortsatt noe: bare den hostede assertion-en kan bevise noe. Et bilde kan kopieres og endres fritt, mens svaret på bevisets adresse styres av utstederen alene.
Open Badges og LinkedIn: hva som går og hva som ikke går
Her rydder vi opp i den vanligste misforståelsen som spøker i mange artikler: LinkedIn leser ikke Open Badge-metadata. Det finnes ingen badge-import der, ingen automatisk sjekk, ingen egen ikon for verifiserte badger. Det LinkedIn har, er profilfeltet «Lisenser og sertifiseringer» med felt for navn, utstedende organisasjon og en URL. Ingenting av dette betyr at LinkedIn har sertifisert eller anerkjent noe.
Det gjør likevel ikke standarden ubrukelig for LinkedIn, tvert imot: bevisadressen hører hjemme i URL-feltet. Klikker noen på «Vis bevis» i profilen, havner de på bevissiden, og bak den ligger den verifiserbare assertion-en. Selve oppføringen kan gjøres klar for mottakerne med ett klikk, med skjemafeltene ferdig utfylt. Hvordan dette ser ut fra deltakernes side, viser guiden til å legge beviset inn i profilen.
Utsted Open Badges uten å gjøre det til et IT-prosjekt
Å implementere standarden selv lønner seg for de færreste arrangører: dere ville trengt permanent tilgjengelige endepunkter for Issuer, BadgeClass og hver enkelt Assertion, i tillegg til tilbakekallingslogikk og et bakt bilde. For arrangementer, webinarer og kurs finnes en ferdig vei: hos OneClickBadge utformer dere et deltakerbevis, og hvert utstedte eksemplar får automatisk sin hostede assertion, tilbakekallingsmekanismen og PDF-en med bilde.
Utdelingen til mange deltakere skjer uten listeopplasting, via en selvbetjeningslenke som dere deler etter arrangementet. Hvorfor dette også er en personvernbeslutning når det gjelder bevis, står på siden Sertifikater til mange deltakere.
Og hva med Open Badges 3.0?
Versjon 3.0 flytter standarden over på W3C Verifiable Credentials, en modell med kryptografiske signaturer og mer kontroll hos mottakeren. For økosystemer i høyere utdanning og langlivede utdanningsbevis er det riktig retning. For bruksområdet arrangementsdeltakelse er 2.0 i hostet form den pragmatiske situasjonen i dag: alle vanlige verifiseringsverktøy forstår den, tilbakekalling fungerer, og ingen trenger å håndtere wallets eller nøkler. Derfor satser vi på 2.0 hosted og følger 3.0 videre i ro og mak.
Les også
Ofte stilte spørsmål
- Gjenkjenner eller verifiserer LinkedIn Open Badges?
- Nei. LinkedIn leser ikke metadataene og sjekker ingenting; feltet Lisenser og sertifiseringer tar rett og slett imot et navn, en organisasjon og en URL. Verifiserbarheten kommer fra utstederen: URL-en fører til bevissiden, og bak den kan den hostede assertion-en hentes når som helst.
- Hva skiller et Open Badge fra et PDF-bevis?
- PDF-en er en fil, et Open Badge er en tilstand som kan hentes. En PDF kan hvem som helst sende videre eller lage på nytt, uten at noen merker det. Assertion-en ligger hos utstederen, kan sjekkes maskinelt og tilbakekalles ved behov. I praksis trenger dere begge deler: PDF-en til mappen og skriveren, bevislenken til alt som skal kunne verifiseres.
- Trenger mottakere en konto eller en wallet?
- Ikke for Open Badges 2.0 i hostet form. Beviset er en offentlig URL, og bildet og PDF-en er vanlige filer. Hos OneClickBadge henter deltakerne beviset via en lenke og legger det inn i LinkedIn-profilen gjennom oss, uten å logge inn.
- Hva koster det å utstede Open Badges?
- Selve standarden koster ingenting, den er åpen. Hos OneClickBadge oppretter dere et arrangement og setter opp beviset og den hostede utgaven med en gratis konto; hva som gjelder utover det, ser dere når dere oppretter det. Mottakere betaler aldri noe og trenger ingen konto.
- Er Open Badges forfalskningssikre?
- Den hostede assertion-en er det, innenfor rammene av metoden: den er gyldig nettopp når den ligger på sin id-adresse på utstederens server, og den som ville forfalske det, måtte kontrollere den serveren. Selve bildet er fortsatt mulig å kopiere, så det pålitelige er alltid adressen bak.
Kilder
Opplysninger om eksterne plattformer sist kontrollert 12. juli 2026.