Open Badges: den öppna standarden bakom kontrollerbara bevis

Standarden delar upp ett bevis i tre delar, och uppdelningen är smartare än den först verkar. Issuer beskriver vem som utfärdar: namn, webbplats, kontakt. BadgeClass beskriver vad som tilldelas: bevisets titel, beskrivning, kriterier och bild. Assertion är slutligen den enskilda tilldelningen: just den här personen fick den här BadgeClass det här datumet.

På så sätt behöver beskrivningen av en intygstyp bara finnas en gång, oavsett om ni delar ut den till 20 eller 2 000 personer. Så här ser en verklig assertion ur vårt system ut, bara token är förkortad:

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

Två detaljer är värda en andra blick. Fältet badge är bara en adress: där ligger BadgeClass, som i sin tur pekar på Issuer, och så tar sig ett kontrollverktyg vidare genom hela kedjan. Och som recipient står här adressen till intygssidan; en e-postadress, inte ens en hashad, förekommer ingenstans. Det offentliga dokumentet klarar sig alltså utan direkta kontaktuppgifter. Personens namn står på den länkade intygssidan, där personen själv skrev in det när intyget hämtades.

Specifikationen känner två vägar till att göra en assertion kontrollerbar. Vid signerade badges bär dokumentet en kryptografisk signatur från utfärdaren, det bevisar alltså sig självt, men kräver nyckelhantering hos utfärdaren. Vid hostade badges gäller en enklare regel: en assertion är äkta så länge den går att hämta på sin egen id-adress hos utfärdaren. Att kontrollera betyder då helt enkelt att hämta URL:en och jämföra.

Det hostade förfarandet har en underskattad fördel: den rena återkallelsen. När utfärdaren drar tillbaka ett bevis svarar samma adress från och med då med HTTP-status 410 och ett kort dokument med raden ”revoked: true”. Ett återkallat intyg blir alltså inte bara tyst. Det säger aktivt ifrån att det inte längre gäller. Så gör vi det på OneClickBadge också, till exempel när ett intyg av misstag har utfärdats två gånger.

En detalj i standarden är nästan poetisk: ”baking”. Badge-grafiken, oftast en PNG, får sin assertion tillsammans med kontrolladressen inbäddad direkt i bildfilen, tekniskt som ett iTXt-textblock med nyckelordet openbadges. Bilden ser exakt likadan ut efteråt men bär sin kontrollväg inuti sig: den som drar filen till ett kontrollverktyg hamnar hos sin assertion, oavsett hur många nedladdningar och chattar bilden har vandrat genom.

Rangordningen är viktig: bara den hostade assertionen kan bevisa något. En bild går att kopiera och ändra hur som helst, medan svaret på bevisadressen kontrolleras av utfärdaren ensam.

Här reder vi ut det vanligaste missförståndet som spökar i många artiklar: LinkedIn läser inte Open Badge-metadata. Det finns ingen badge-import där, ingen automatisk kontroll, ingen särskild symbol för verifierade badges. Det LinkedIn har är profilavsnittet ”Licenser och certifikat” med fält för namn, utfärdande organisation och en URL. Ingenting av det innebär att LinkedIn har certifierat eller godkänt något.

Därför är standarden ändå inte oanvändbar för LinkedIn, tvärtom: i URL-fältet hör bevisadressen hemma. Den som klickar på ”Visa certifikat” i profilen hamnar på intygssidan, bakom vilken den kontrollerbara assertionen ligger. Själva posten går att förbereda för mottagarna med ett klick, med formulärfälten redan ifyllda. Hur det ser ut ur deltagarnas perspektiv visar guiden om att lägga in intyget i profilen.

Att implementera själva standarden lönar sig för de färraste arrangörer: ni skulle behöva ständigt nåbara slutpunkter för Issuer, BadgeClass och varje enskild assertion, dessutom återkallelselogik och en bakad bild. För event, webbinarier och utbildningar finns en färdig väg: på OneClickBadge utformar ni ett deltagarintyg, och varje utfärdat exemplar får automatiskt sin hostade assertion, återkallelsemekanismen och PDF:en med bild.

Att dela ut det till många deltagare sker utan listuppladdning, via en hämtlänk som ni delar efter eventet. Varför det just i bevisfrågan också är ett dataskyddsbeslut står på sidan Intyg till många deltagare.

Version 3.0 flyttar standarden till W3C Verifiable Credentials, en modell med kryptografiska signaturer och mer kontroll hos mottagaren. För högskolornas ekosystem och långlivade utbildningsbevis är det rätt riktning. För användningsfallet eventdeltagande är 2.0 i hostad form det pragmatiska läget i dag: alla vanliga kontrollverktyg förstår det, återkallelsen fungerar, och ingen behöver hantera plånböcker eller nycklar. Därför satsar vi på 2.0 hostad och fortsätter att lugnt hålla ett öga på 3.0.