Open Badges : le standard ouvert derrière des justificatifs vérifiables

Le standard découpe un justificatif en trois parties, et cette séparation est plus astucieuse qu'il n'y paraît. L'Issuer décrit qui délivre : nom, site web, contact. La BadgeClass décrit ce qui est décerné : le titre du justificatif, sa description, ses critères, son image. L'Assertion, enfin, est l'attribution individuelle : cette personne précise a reçu cette BadgeClass à cette date.

Ainsi, la description d'un type d'attestation n'a besoin d'exister qu'une seule fois, que vous la décerniez à 20 ou à 2 000 personnes. Voici à quoi ressemble une vraie assertion issue de notre système, avec seulement le token abrégé :

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

Deux détails méritent un second regard. Le champ badge n'est qu'une adresse : c'est là que se trouve la BadgeClass, qui pointe à son tour vers l'Issuer, et un outil de vérification remonte ainsi toute la chaîne. Et comme recipient figure ici l'adresse de la page d'attestation ; aucune adresse e-mail, pas même hachée, n'apparaît où que ce soit. Le document public se passe donc de coordonnées directes. Le nom de la personne se trouve sur la page d'attestation liée, là où elle l'a saisi elle-même en récupérant son attestation.

La spécification connaît deux manières de rendre une assertion vérifiable. Avec les badges signés, le document porte une signature cryptographique de l'émetteur : il se prouve donc lui-même, mais cela demande une gestion de clés du côté de l'émetteur. Avec les badges hébergés, une règle plus simple s'applique : l'assertion est authentique tant qu'elle reste consultable à sa propre adresse id chez l'émetteur. Vérifier revient alors simplement à appeler l'URL et à comparer.

Le procédé hébergé a un avantage sous-estimé : une révocation propre. Quand l'émetteur retire un justificatif, la même adresse répond aussitôt avec le statut HTTP 410 et un court document portant la ligne « revoked: true ». Une attestation retirée ne se contente donc pas de se taire, elle signale activement qu'elle n'est plus valide. C'est ainsi que nous procédons chez OneClickBadge, par exemple lorsqu'une attestation a été délivrée deux fois par erreur.

Un détail du standard est presque poétique : le « baking ». Le visuel du badge, le plus souvent un PNG, reçoit son assertion et son adresse de vérification directement dans le fichier image, techniquement sous forme de bloc de texte iTXt avec le mot-clé openbadges. L'image a exactement le même aspect ensuite, mais elle porte son chemin de vérification en elle : glissez le fichier dans un outil de vérification et vous arrivez à l'assertion, peu importe le nombre de téléchargements et de discussions par lesquels l'image est passée.

L'ordre de priorité reste important : seule l'assertion hébergée peut apporter la preuve. Une image se copie et se modifie à volonté, alors que la réponse à l'adresse du justificatif est contrôlée par le seul émetteur.

Ici, nous dissipons le malentendu le plus répandu, celui qui hante tant d'articles : LinkedIn ne lit pas les métadonnées Open Badge. Il n'y a pas d'import de badge, pas de vérification automatique, pas d'icône particulière pour les badges vérifiés. Ce que LinkedIn propose, c'est la rubrique de profil « Licences et certifications », avec des champs pour un nom, un organisme émetteur et une URL. Rien de tout cela n'est pour autant certifié ou reconnu par LinkedIn.

Le standard n'en est pas pour autant inutile sur LinkedIn, au contraire : c'est l'adresse du justificatif qui a sa place dans le champ URL. Qui clique sur « Afficher le justificatif » dans le profil arrive sur la page d'attestation, derrière laquelle se trouve l'assertion vérifiable. L'entrée elle-même se prépare pour les destinataires en un seul clic, avec les champs du formulaire déjà remplis. Ce que cela donne du point de vue des participants, le guide pour l'ajouter au profil le montre.

Implémenter le standard soi-même n'en vaut la peine que pour très peu d'organisateurs : il vous faudrait des points d'accès joignables en permanence pour l'Issuer, la BadgeClass et chaque assertion, plus une logique de révocation et une image « bakée ». Pour les événements, les webinaires et les formations, une voie toute prête existe : chez OneClickBadge, vous concevez une attestation de participation, et chaque exemplaire délivré reçoit automatiquement son assertion hébergée, le mécanisme de révocation et le PDF avec l'image.

La distribution à de nombreux participants se fait sans importer la moindre liste, via un lien de récupération que vous partagez après l'événement. Pourquoi c'est aussi une décision de protection des données quand il s'agit de justificatifs, la page Attestations pour de nombreux participants l'explique.

La version 3.0 fait basculer le standard vers les W3C Verifiable Credentials, un modèle avec signatures cryptographiques et davantage de contrôle du côté du destinataire. Pour les écosystèmes universitaires et les preuves de formation à longue durée de vie, c'est la bonne direction. Pour le cas d'usage de la participation à un événement, la 2.0 dans sa forme hébergée est aujourd'hui le choix pragmatique : tout outil de vérification courant la comprend, la révocation fonctionne, et personne n'a à gérer de portefeuilles ni de clés. Nous misons donc sur la 2.0 hébergée et nous continuons d'observer la 3.0 sans nous presser.