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 certifikattyp bara finnas en gång, oavsett om du 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 certifikatsidan; 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 certifikatsidan, där personen själv skrev in det när certifikatet hämtades.

Specifikationen anger två sätt att göra en assertion kontrollerbar. Vid signerade badgar 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 badgar 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 certifikat 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 certifikat 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 kommer fram till assertionen, 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å verifieringsadressen 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 badgar. 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 verifieringsadressen hemma. Den som klickar på ”Visa certifikat” i profilen hamnar på certifikatsidan, 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 certifikatet i profilen.

Att implementera själva standarden lönar sig för de färraste arrangörer: du 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 du ett deltagarcertifikat, 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 du delar efter eventet. Varför det just i bevisfrågan också är ett dataskyddsbeslut står på sidan Certifikat 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.