Badges themselves are very simple files.
Often the badge information is encoded inside an image, usually a PNG.
So the image contains both:
• the visual badge
• the structured metadata describing the credential
One file, both human-friendly and machine-readable.
Other times these are simple json files.
--
Where things get interesting is with #ActivityPub.
@badgefed uses ActivityPub as a transport layer for decentralization, and also as a way to add social features.
BadgeFed issues credentials, but it wraps the OpenBadge inside an ActivityPub Note.
The actor creating that note is the badge issuer. <-- important!
--
This is actually very similar to how a Mastodon post works when you post a image.
Imagine:
• the image = the badge
• the post = the description of the recognition
Once published, anyone in the #Fediverse can interact with it:
reply, comment, like, boost, quote, or follow (and block) the issuer.
Badges become social objects.
ActivityPub is also used for federation.
Badge issuers (ActivityPub actors) can follow other issuers.
When a badge is issued, a Create activity is federated.
Other servers receive that activity and can store a local copy of the badge.
This works very similarly to how Mastodon servers cache posts.
Because of that, badges can also be:
• revoked using the Delete activity
• updated using the Update activity
Again, this reuses existing ActivityPub verbs instead of inventing a new protocol or new spec.
Simple primitives, (I love how simple it is), powerful results.
--
Verification is also straightforward.
The #OpenBadge issuer URL points to the ActivityPub actor URL.
That means the same actor who published the badge also owns the public/private key pair used in ActivityPub.
So the actor identity and the badge issuer identity match.