Open Badges: avoin standardi todennettavien todistusten takana

Standardi jakaa todistuksen kolmeen osaan, ja jako on fiksumpi kuin miltä se aluksi vaikuttaa. Issuer kuvaa, kuka myöntää: nimi, verkkosivu, yhteystieto. BadgeClass kuvaa, mitä myönnetään: todistuksen otsikko, kuvaus, kriteerit ja kuva. Assertion on lopulta yksittäinen myöntö: tämä yksi henkilö sai tämän BadgeClassin tänä päivänä.

Näin todistustyypin kuvauksen tarvitsee olla olemassa vain kerran, myönnätte sen sitten 20 tai 2 000 ihmiselle. Tältä näyttää aito Assertion meidän järjestelmästämme, vain tunniste on lyhennetty:

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

Kaksi yksityiskohtaa ansaitsee toisen katseen. Kenttä badge on pelkkä osoite: siellä on BadgeClass, joka puolestaan osoittaa Issueriin, ja näin tarkistustyökalu etenee koko ketjun läpi. Ja recipient-kentässä on tässä todistussivun osoite; sähköpostiosoitetta, ei edes tiivistettyä, ei näy missään. Julkinen asiakirja tulee siis toimeen ilman suoria yhteystietoja. Henkilön nimi on linkitetyllä todistussivulla, siellä, mihin hän itse kirjoitti sen todistusta noutaessaan.

Spesifikaatio tuntee kaksi tapaa tehdä Assertionista todennettava. Allekirjoitetuissa badgeissa asiakirja kantaa myöntäjän kryptografista allekirjoitusta, joten se todistaa itsensä, mutta vaatii siihen avaintenhallinnan myöntäjän puolella. Isännöidyissä badgeissa pätee yksinkertaisempi sääntö: Assertion on aito niin kauan kuin se on haettavissa omasta id-osoitteestaan myöntäjältä. Todentaminen tarkoittaa silloin yksinkertaisesti sitä, että haetaan URL ja verrataan.

Isännöidyllä menettelyllä on aliarvioitu etu: siisti mitätöinti. Kun myöntäjä vetää todistuksen pois, sama osoite vastaa siitä hetkestä alkaen HTTP-tilakoodilla 410 ja lyhyellä asiakirjalla, jossa on rivi „revoked: true“. Poisvedetty todistus ei siis katoa huomaamatta. Se ilmoittaa aktiivisesti, ettei ole enää voimassa. Näin teemme myös OneClickBadgessa, esimerkiksi kun todistus on vahingossa myönnetty kahteen kertaan.

Yksi standardin yksityiskohta on melkein runollinen: „baking“. Badge-grafiikka, useimmiten PNG, saa Assertioninsa ja tarkistusosoitteensa upotettuna suoraan kuvatiedostoon, teknisesti iTXt-tekstilohkona avainsanalla openbadges. Kuva näyttää sen jälkeen täsmälleen samalta, mutta kantaa tarkistuspolkuaan sisällään: kun tiedoston vetää tarkistustyökaluun, päätyy Assertioniin riippumatta siitä, kuinka monen latauksen ja chatin läpi kuva on kulkenut.

Tärkeä on järjestys: todistaa voi vain isännöity Assertion. Kuvan voi kopioida ja muokata miten tahansa, mutta vastauksen todistusosoitteessa hallitsee yksin myöntäjä.

Tässä oikaisemme yleisimmän väärinkäsityksen, joka kummittelee monessa artikkelissa: LinkedIn ei lue Open Badge -metatietoja. Siellä ei ole badgejen tuontia, ei automaattista tarkistusta eikä erillistä merkkiä todennetuille badgeille. LinkedInissä on profiiliosio „Lisenssit ja sertifikaatit“, jossa on kentät nimelle, myöntävälle organisaatiolle ja URL-osoitteelle. Mikään tästä ei tarkoita, että LinkedIn olisi sertifioinut tai hyväksynyt mitään.

Silti standardi ei ole LinkedInille hyödytön, päinvastoin: URL-kenttään kuuluu todistusosoite. Kun profiilissa klikkaa „Näytä todistus“, päätyy todistussivulle, jonka takana on todennettava Assertion. Merkinnän voi valmistella osallistujille yhdellä klikkauksella, lomakekentät valmiiksi täytettyinä. Miltä tämä näyttää osallistujien näkökulmasta, sen näyttää opas todistuksen lisäämiseen profiiliin.

Standardin toteuttaminen itse kannattaa harvalle järjestäjälle: tarvitsisitte pysyvästi tavoitettavat päätepisteet Issuerille, BadgeClassille ja jokaiselle yksittäiselle Assertionille, lisäksi mitätöintilogiikan ja bakingilla varustetun kuvan. Tapahtumia, webinaareja ja koulutuksia varten se on valmiina: OneClickBadgessa suunnittelette osallistumistodistuksen, ja jokainen myönnetty kappale saa automaattisesti isännöidyn Assertioninsa, mitätöintimekanismin ja PDF:n kuvineen.

Jakaminen monelle osallistujalle sujuu ilman listan lataamista, itsenoutolinkin kautta, jonka jaatte tapahtuman jälkeen. Miksi tämä on todistusten kohdalla myös tietosuojaratkaisu, sen kertoo sivu Todistukset monelle osallistujalle.

Versio 3.0 siirtää standardin W3C Verifiable Credentials -malliin, jossa on kryptografiset allekirjoitukset ja enemmän hallintaa vastaanottajalla. Korkeakoulujen ekosysteemeille ja pitkäikäisille koulutustodistuksille se on oikea suunta. Tapahtumaosallistumisen käyttötapaukseen 2.0 isännöidyssä muodossaan on tänään pragmaattinen taso: jokainen yleinen tarkistustyökalu ymmärtää sen, mitätöinti toimii, eikä kenenkään tarvitse hallita lompakoita tai avaimia. Siksi luotamme 2.0:aan isännöitynä ja seuraamme 3.0:aa rauhassa.