From Badges to BadgeChain: Part 1

This post kicks off a series of five blog posts designed to explore, inform, and encourage public discussions about the possibilities, opportunities, and challenges arising at the intersection of Open Badges and blockchain technology.
Carla Casilli & Kerri Lemoie

Starting from open

A brief history of Open Badges

Over the next few years, the Open Badges team experimented with this novel idea even further, ultimately spinning out of Mozilla to form The Badge Alliance, a network of organizations helping to build and sustain the open badges ecosystem. The BA accomplished a great deal in its first six months: in addition to hosting regular open community calls, speaking with subject matter experts, building software, presenting at conferences, and sharing thinking publicly through blogs and discussions, the team shepherded over ten Working Groups aimed at addressing a variety of ecosystem development areas including Research, Higher Ed, Endorsement, Workforce, Policy and the Open Badges Standard.

The power of open

Open Badges technology: an evolutionary process

The original 0.5 specification grouped all badge metadata in a single JSON file. The subsequent 1.0 specification split the metadata into three JSON files: assertion, the earned badge record; badge class, the generic badge description; and issuer object, the issuer information. When the specification evolved from 1.0 to 1.1, it changed from pure JSON to JSON-LD. The 1.0 to 1.1 iteration aimed to maintain the integrity of badges built on the original 1.0 standard. In other words, it sought to ensure that badges built on platforms using the earlier specification would not break.

Even with the 1.1 specification, badges can become siloed on issuers’ servers because they are hosted as isolated files and rely heavily on web-hosted resources for links to evidence, criteria, and other metadata. In a few high stakes environments, anxiety related to rigor, fraud, duplication, and spoofing have influenced Open Badges conversations. Calls for greater attention to challenges related to validation, earner identity, evidence storage and criteria remain open.

Alongside the Open Badges Specification the Mozilla badge backpack made its debut, although its documentation is meager at best. The backpack was originally imagined as a reference implementation — an example — of a badge referatory. With it, the Open Badges team sought to ensure that earned badges could be stored privately until an earner decided to share any and all of their badges publicly. There is a catch to the validation process for badges held in backpacks, or really, badges displayed anywhere. If an issuer stops hosting data referenced by a badge, that badge becomes orphaned (sometimes jokingly referred to as a zombie badge) and ultimately becomes impossible to validate, even if previously it had been a properly functioning badge. This complexity weakens individual control over earned and owned badges by limiting the ongoing validation of accomplishments to issuers. In other words, an orphaned badge puts the historical record of an individual’s earned achievements at risk, if it’s kept in a backpack or not. For an initiative that endeavors to put earners at the center of the learning recognition experience, this presents a true philosophical conflict.

Understandably, certain aspects of ecosystem development have slowed due to worry over some of the issues discussed here. Happily, the BadgeChain team’s exploration of new technology complements the Badge Alliance’s preparation for the Open Badges Specification 2.0.

What’s next

We welcome your questions and comments and encourage you to contact us at Thanks!

Open badges + digicred, workforce + edu strategist. Media psych grad / Design undergrad. Co-founder: #BadgeChain #openbadges #badgealliance #IMSbadges

Open badges + digicred, workforce + edu strategist. Media psych grad / Design undergrad. Co-founder: #BadgeChain #openbadges #badgealliance #IMSbadges