Open Badges: lo standard aperto dietro le credenziali verificabili

Lo standard scompone una credenziale in tre parti, e la divisione è più intelligente di quanto sembri all'inizio. L'Issuer descrive chi rilascia: nome, sito web, contatto. La BadgeClass descrive cosa viene assegnato: titolo della credenziale, descrizione, criteri, immagine. L'Assertion, infine, è il singolo rilascio: questa persona ha ricevuto questa BadgeClass in questa data.

Così la descrizione di un tipo di attestato deve esistere una sola volta, che lo assegniate a 20 o a 2.000 persone. Ecco come si presenta una vera Assertion del nostro sistema, con il solo token abbreviato:

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

Due dettagli meritano un secondo sguardo. Il campo badge è soltanto un indirizzo: lì si trova la BadgeClass, che a sua volta rimanda all'Issuer, e così uno strumento di verifica percorre tutta la catena. Come recipient, invece, qui compare l'indirizzo della pagina dell'attestato; un indirizzo email, anche in forma hash, non appare da nessuna parte. Il documento pubblico fa quindi a meno di qualsiasi dato di contatto diretto. Il nome della persona si trova sulla pagina dell'attestato collegata, là dove l'ha inserito lei stessa al momento del ritiro.

La specifica prevede due modi per rendere verificabile un'Assertion. Con i badge firmati il documento porta una firma crittografica di chi lo rilascia, quindi si dimostra da solo, ma richiede la gestione delle chiavi dalla parte di chi rilascia. Con i badge ospitati vale una regola più semplice: l'Assertion è autentica finché resta consultabile al proprio indirizzo id presso chi l'ha rilasciata. Verificare significa allora semplicemente richiedere l'URL e confrontare.

Il metodo ospitato ha un vantaggio sottovalutato: la revoca pulita. Se chi ha rilasciato ritira una credenziale, lo stesso indirizzo risponde da quel momento con lo stato HTTP 410 e un breve documento che riporta la riga «revoked: true». Un attestato ritirato non sparisce e basta: dichiara attivamente di non valere più. Facciamo così anche in OneClickBadge, per esempio quando un attestato è stato rilasciato due volte per errore.

Un dettaglio dello standard è quasi poetico: il «baking». La grafica del badge, di solito un PNG, riceve la propria Assertion insieme all'indirizzo di verifica direttamente dentro il file immagine, tecnicamente come blocco di testo iTXt con la parola chiave openbadges. Dopo l'immagine resta identica, ma porta con sé il proprio percorso di verifica: chi trascina il file in uno strumento di verifica arriva all'Assertion, per quanti download e chat l'immagine sia passata.

Resta importante l'ordine di priorità: solo l'Assertion ospitata può fare da prova. Un'immagine si può copiare e modificare a piacere, mentre la risposta all'indirizzo della credenziale è controllata soltanto da chi la rilascia.

Qui sgombriamo il campo dall'equivoco più diffuso, quello che si aggira in tanti articoli: LinkedIn non legge i metadati degli Open Badge. Non c'è nessun import di badge, nessuna verifica automatica, nessun simbolo speciale per i badge verificati. Quello che LinkedIn ha è la sezione del profilo «Licenze e certificazioni», con i campi per il nome, l'organizzazione che rilascia e un URL. Nulla di tutto ciò significa che LinkedIn abbia certificato o riconosciuto qualcosa.

Questo non rende però lo standard inutile per LinkedIn, anzi: nel campo URL va l'indirizzo della credenziale. Chi nel profilo tocca «Mostra credenziale» arriva sulla pagina dell'attestato, dietro la quale c'è l'Assertion verificabile. La voce stessa si può preparare per chi la riceve con un solo clic, con i campi del modulo già compilati. Come appare questo dal punto di vista dei partecipanti lo mostra la guida per aggiungere l'attestato al profilo.

Implementare lo standard da soli conviene a pochissimi organizzatori: vi servirebbero endpoint sempre raggiungibili per Issuer, BadgeClass e ogni singola Assertion, più la logica di revoca e un'immagine con il baking. Per eventi, webinar e corsi di formazione la strada è già pronta: in OneClickBadge progettate un attestato di partecipazione e ogni copia rilasciata riceve in automatico la sua Assertion ospitata, il meccanismo di revoca e il PDF con l'immagine.

La distribuzione a molti partecipanti avviene senza caricare alcuna lista, tramite un link self-service che condividete dopo l'evento. Perché proprio sul tema delle credenziali questa sia anche una scelta di privacy lo spiega la pagina Attestati per molti partecipanti.

La versione 3.0 porta lo standard sulle Verifiable Credentials del W3C, un modello con firme crittografiche e più controllo dalla parte di chi riceve. Per gli ecosistemi universitari e per i titoli di studio destinati a durare nel tempo è la direzione giusta. Per il caso d'uso della partecipazione a un evento, la 2.0 in forma ospitata è oggi la scelta pragmatica: ogni strumento di verifica diffuso la comprende, la revoca funziona e nessuno deve gestire wallet o chiavi. Per questo puntiamo sulla 2.0 hosted e continuiamo a osservare con calma la 3.0.