From Badges to BadgeChain: Part 3.1

June 2nd, 2016 | Carla Casilli and Kerri Lemoie

The Combined Possibilities Part

This post is the third in 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.
Part 1: “
The Open Badges Part
Part 2: “
The Blockchain Part

Carla Casilli & Kerri Lemoie

Starting from open

Over the last five years, we have dedicated ourselves to working in the open as founding members of the open badges revolution. We continue to share our insights publicly in this blog post, exploring the possibilities of combining badges and blockchain, two innovative, new technologies. As always, we aim to keep the language simple and straightforward. (If you’re brand new to open badges, you can find the original open badges white paper here.)

A vital open badges ecosystem

In our first post, we dived into the definition and history of open badges, providing information regarding the technology that underpins them. In our second post, we focused on defining blockchain, hinted at its adoption rate, and referenced its increasing power in the software implementation world. Here we’ll explore some of the ways that blockchain can serve the needs of the open badges ecosystem. That means investigating issues and impasses that currently beleaguer open badges and their related ecosystem development. Areas we’ll cover include hosting, identity, verification, and privacy; however, we acknowledge that there are additional issues that impact further open badges ecosystem development, including evidence and endorsement.

Here it’s important to state that all of our comments addressing concerns and roadblocks are noted with this caveat: the open badges ecosystem is vital and growing in dynamic ways and has been for years. We assert that its continued surging growth is a direct response to the intrinsic hypothesis embedded in the open badges initiative — that many forms of learning were/are going unrecognized and under-appreciated. In this important aspect, the open badges effort, regardless of its current issues, is succeeding wildly in its aim of representing learning in new and beneficial ways.

In the following sections, we’ll link existing open badges development with blockchain possibilities, some of which are conceptual concerns and some of which are affordances offered by a new technology.

Stakeholders

Currently the open badges ecosystem is composed of at least three essential audiences: earners (people who earn recognition through badges), issuers (organizations and individuals who provide recognition through badges) and consumers (individuals and organizations that make use of / evaluate badges for their own purposes). These different constituencies have different drivers, desires, and requirements. The open badges ecosystem has been structured to acknowledge, accommodate, and nurture each of these audiences. Think of them as a three legged stool: remove one of the legs and the proposed ecosystem structure topples over. Each of these audiences plays important and reinforcing roles at different times. In this post (3.1) and the follow-on sister post (3.2), we’ll explore how a BadgeChain implementation could affect their influence, address their difficulties, and encourage continued development.

Issuer consideration: lifetime hosting

In the existing software construct, open badges contain three files: the assertion, the badge class, and the issuer object. The last acts as the metadata reference to the issuer. Once issued, badges become an artifact that must be hosted permanently. Right now, most badges typically reside on the originating badge issuers’ servers and, somewhat like transcripts, they must remain hosted during the life of the badge, which may be as long as a lifespan or as long as the earner or consumer requires them.

Badges with signed assertions require issuers to host private keys for the life of the badge. Baked into these arrangements are implicit issues of trust intertwined with explicit financial, physical, and social capital costs. While this aspect of participation is not entirely insurmountable, it does complicate long term viability. For some issuers or wannabe issuers, this requirement directly infringes on their ability to fully engage in the open badges ecosystem.

BadgeChain viewpoint

With the blockchain construct, responsibility for information accuracy shifts away from the (hosting) issuer as the primary reference point to the information itself. So how does this work? The hosting requirement is distributed to all nodes on the blockchain. All badge metadata information is embedded within the blockchain and permanently hosted by all nodes participating in the blockchain. Consequently, there is no requirement for issuers to host badges because that information is hosted on the blockchain itself.

As long as the chain (or ledger) exists, information about any badge on the ledger will be available, regardless of whether or not the badge issuer goes out of business, stops issuing badges, or disappears altogether. Obviously, issuers are essential to the open badges ecosystem; however, with blockchain, their hosting responsibilities and to a certain degree, their requirement for information maintenance, end upon badge issuance.

Earner + Consumer consideration: zombie badges

If by some chance a badge is cut loose from its hosting location, whether accidentally or intentionally, it becomes a potential liability to both the earner and the open badges ecosystem. Why? Because without the vital hosting reference links that confirm it, the badge can no longer be validated or verified. Consequently, the badge becomes orphaned and, for the most part, useless to potential consumers. In colloquial terms, this is a zombie badge: dead in most respects despite any original implied or actual value.

BadgeChain viewpoint

With blockchain, the zombie badge concern can be not only mitigated but dispensed with altogether. Blockchain is built upon a ledger concept, and because the ledger acts as an ongoing reference point, badges cannot become zombified. Why? Because issuer verification is written into the ledger when the badge is written into the ledger: verification becomes an artifact of the issued badge.

Issuer + Earner + Consumer consideration: security + evidence

The open badges specification references external urls that may or may not be hosted on the issuers’ servers. These urls include the criteria, the part of the metadata that describes earning, and the evidence, the part of the metadata that indicates work requirements. Currently, both criteria and evidence each have their own url. While the 2.0 specification work is exploring alternatives to existing structural elements of the badge metadata, like embedding criteria content directly in the badge and allowing evidence to refer to an array of urls with identifiers, even these alterations leave holes in verifiability and validation.

BadgeChain viewpoint

Because badge evidence can be a file or website accessible via a url which we understand to be unreliable. Evidence plays a critical role as it accomplishes two things: it clearly indicates a badge’s learning/earning requirements, and it provides proof to consumers of completion. Evidence that a consumer will evaluate on their own terms. With the blockchain, it is possible to store evidence files, whether or not they are videos, content, audio. etc. Storj.io & bitproof.io are two such examples of services that will encrypt and store files.

A further possibility involves combining the ledger capability of blockchain with the distributed web, two peer-to-peer systems. Projects like IPFS (Interplanetary File System) host files and web pages on a distributed system. It’s conceivable that viewers (most likely consumers or proposed consumers) of the files could also host them. Regarding open badges, this idea could be extended to include audiences acting as hosts for evidence files. Now it’s a bit futuristic, but using this scenario, it’s possible that this include baked badges as well: a slightly deeper exploration can be found here.

Issuer + Earner + Consumer consideration: data

The data from open badges is currently inaccessible unless issuers volunteer it or badge collection platforms like the Mozilla Backpack provide it. Even today, it’s difficult to ascertain which badges have been claimed or which badges have been viewed / consumed. And yet, inquiries about open badges issuing, distribution, and use are among the most common requests heard today. How many organizations are issuing badges? Who are they? What badges are they issuing? How many are they issuing? Are issued badges being claimed by earners? How many earned badges are being viewed and consumed? Who is consuming them? Are patterns emerging?

No issuer wants their badges to sit idly on their servers, unclaimed or even unacknowledged, but the current open badges infrastructure allows for that unintended possibility. While some issuing platforms provide ways for earners to share their badges publicly, not every issuer does. Additionally, some platforms have created an interface that links to the Mozilla open badges backpack, a reference implementation of a badge repository, sharing, and display site, but it’s not a requirement of the Open Badges Specification. And even though many badge earners opt to push their badges to a badge collection platforms like the Mozilla backpack, all of that content is still only a subset of all badges issued.

BadgeChain viewpoint

Once again, the value of a ledger that records all transactions reveals itself. Not only is the ledger hosted in a distributed manner, but transactions, once they are added to blocks, become public. This is a dramatic improvement in badge data transparency. Generally speaking, it is possible for issuers, badge classes and assertions to be publicly accessible on blockchain. The public nature of blockchain makes data much more accessible and referenceable than previously has been possible — even in a complicated example of multiple chains containing multiple badges and other credentials.

Data-derived answers to the considerations noted above will reveal the true nature of open badges: as powerful, information-rich tools. By providing a window into what makes a badge, or series of badges, useful and valuable, many types of connections can be generated, e.g., issuers to other issuers, earners to opportunities, and consumers to issuers and earners. This information can help to create a virtuous circle that benefits the entire open badges ecosystem.

Of course, as with all personal digital data, privacy issues must be considered closely. Interestingly, blockchain implementations of open badges may differ from how the majority of blockchain transactions currently work. These considerations and challenges are precisely the areas that BadgeChain is exploring.

— —

A word about BadgeChain + funding

BadgeChain is an open source think tank focused on the intersection of open badges and the blockchain for the public good. While we currently are investigating blockchain affordances with regards to learning recognition (i.e., not developing specific tools), we have ideas! Lots of ideas. And we are searching for funding opportunities to continue this exploration and possibly build/expand upon tools both existing and new. If you are intrigued by this work and have ideas of your own pertaining to development activities, please contact us. We are available for discussions regarding general consulting as well as specific projects.

From blockchain to BadgeChain (1)

May 31st, 2016 | Serge Ravet

While not initially coined to describe a technical object, but rather a team of Open Badge enthusiasts willing to exploit the benefits of blockchains, BadgeChain is also a word that might be used in the future to describe a new technical object resulting from the merger of blockchains and Open Badges.

When we started the BadgeChain group, the initial idea was to explore how blockchains could contribute towards improving the Open Badge technology and experience. There are a number of limitations to what one can do with Open Badges today that blockchains seem to be able to outsmart. Our initial reflection looked at the application of blockchain ideas to Open Badges. What has not yet been explored is the application of Open Badge ideas to blockchains: what could we do to blockchains if they used what we know about Open Badges?

About Trust

Both Open Badges and blockchains are related to trust but they do it in almost opposite ways. As I have written many times, Open Badges are trust statements that could be combined to create chains and networks of trust. The information on how the members of the network trust each other can be used as the basis to establish trustworthy transactions — if 32 Open Badge experts trust Slava’s expertise on badges as well as 53 clients, I’m inclined to trust Slava to work with me on my next project.

Blockchains on the other hand are a means to establish trustworthy transactions even if those engaged in transactions do not trust each other. The trustworthiness of the transactions is not a property depending on the participants, their behaviour or the data they provide but on an algorithm controlling the trustworthiness of the next blocks added to the chain. The blockchain technology was designed to eliminate the human factor from making the decision on whether a transaction is trustworthy or not.

BadgeChain vs. blockchain

NB: many articles on the Web describe blockchains as trustless. What is meant is that trustworthy transactions are possible without the involvement of any trusted authority (a bank, a notary or a registrar) and despite the fact that the parties involved do not trust each other. Trust is fully embedded in the blockchain infrastructure and does not need human intervention.

With the BadgeChain, trust is a property emerging from the participants’ behaviour, with blockchain trust is a property that ignores participants behaviour. One builds dynamic multidimensional networks i, the other an ever growing unidimensional chain. One is able to add and delete data (withdraw trust), the other can only add data (write only). One has emerged from the world of informal education, the other from the formal world of international business and finance.

BadgeChain vs Blockchain

From the previous description, any attempt at combining blockchains with Open Badges into a new technical object might sound like the marriage of the carp and rabbit! Yet, it is what we are going to try to achieve.

BadgeChain = Open Badges * blockchains

Different approaches are possible for merging Open Badges with blockchains:

  • Assimilation: the blockchain provides a more secure way to store credentials, so institutions do not have to bother with Open Badges.
  • Integration: the blockchain is a distributed database, where badges are stored as they would be in any other database (MySQL, Oracle, Fedora, etc.).
  • Accommodation: Open Badges are used to rethink blockchain architecture, protocols and algorithms

The assimilation model is already in action and will soon be adopted by all those who do not see in Open Badges anything more than credentials. Let’s face it, blockchains, even in their infant stage, are far superior to the current Open Badge technology for storing academic credentials. Moreover it is an opportunity for institutions to reassess their power as credentialing authorities. After all, why bother with Open Badges if any institution can create their own private chain and put on it the data they wish. Organisations already in the credentialing business can move directly to the blockchain without having to go through the Open Badges stage.

The integration model is a means for the Open Badge practitioners to continue business as usual while exploiting the unique properties of blockchains to correct some of the shortcomings of the current Open Badge Infrastructure. The integration model has also its drawbacks, like the lack of maturity of blockchain technology, a characteristic shared by the Open Badge infrastructure… There might be advantages in building a future together rather than getting older apart…

One of the main value propositions of the blockchain for integration is the ability create fully trustworthy and easy to verify records. Another main value is its ubiquitous database: the blockchain frees the storage of Open Badges from any individual storage, so badge holders are not forced to choose between one platform or another to store their badges. Service providers (e.g. issuing platforms) will be free to concentrate on added value services rather than trying to improve an idiosyncratic technology.

how could Open Badges help in creating a new type of blockchain exploiting the trust relationships captured by Open Badges?

The accommodation model starts with a question: how could Open Badges help in creating a new type of blockchain exploiting the trust relationships captured by Open Badges? It is what we are going to explore over the next posts, moving gradually away from the current Open Badge infrastructure to a possible BadgeChain infrastructure.

Many thanks to Nate Otto for his comments and suggestions on the first draft of this series of posts.