From ePortfolios to OpenLedgers — via OpenBadges and BlockChains

When I started exploring Open Badges a few years ago, I rapidly realised that not only were they a solution to several of the problems we had with ePortfolios, but they also had the potential to help us reinvent them — the Open Badge Passport initiative is our contribution to this. And now that I have started exploring the possible application of blockchains to Open Badges, I realise that not only were blockchains the perfect solution to a number of Open Badge problems, but they could also be a means to review our ideas on Open Badges altogether.

What is a blockchain?

A blockchain is the historical record of all the transactions between the participants (nodes) of a network. This record is referred to as a ledger, the artefact accountants use for book keeping. Adding new entries to the ledger, or modifying existing ones, is done by adding a new block to the chain — previous blocks are the faithful representation of the ledger’s previous states.

Moreover, the blockchain technology makes ledgers unfalsifiable. How is this possible? By providing a copy of the full ledger to all members of the network and defining an ingenious protocol for adding new blocks to the chain so that even if someone tried to add an invalid block, the network would detect the fraud and reject the chain containing the invalid block.

One vital point about blockchain technology is privacy: while transactions are public, they can be verified without having to know the real identities of the participants. Identities remain masked.

What could the representation of an Open Badge in a blockchain be?

The first time a badge is issued, a block is created to record a set of metadata. In a sense, one could describe the first block as a badge: instead of being “baked” into a picture, the metadata is “baked” into a ledger. If the same badge was issued to 300 people, the first block of the ledger would record that piece of information — a block usually records several transactions.

At this stage, there is a first major difference with the current Open Badge Infrastructure (OBI): the information that a certain badge has been issued to 300 people is now accessible to all the members of the network (they all have a copy of the ledger). A piece of information that would normally be kept hidden behind the walls of issuing platforms is now accessible publicly — and it should be so for making the information verifiable.

This was my first approach to applying blockchains to badges : adding blocks representing badge transactions (issuing badges).

When I realised that issuing a badge was nothing more than adding an entry to a ledger, I wondered: if we forget for a moment that the ledger is used to record badge transactions (issuing, endorsing, revoking), what would a ledger allow us to do with/for/from Open Badges that we could not have done before?

One immediate example that came to my mind is connecting evidence to a badge:

• Each piece of evidence that will be submitted to get a badge is recorded in the ledger
• When all the criteria are covered by sufficient evidence (produced over time in a range of different contexts, etc.) the candidate claims the badge
• When the assessor is satisfied with the quality of the evidence produced, a new entry is added to the ledger (as representation of the badge).

The beauty of this solution is that the very same information recorded in the ledger could be used for many different purposes, for example to manage one’s intellectual property: when I write an article or a blog post, a new entry is added to the ledger. When authors quote or make reference to the article or blog post, they can do it by using the entry in my ledger (each entry has a unique identifier). We can then imagine that each time a reference is made, a BitofTrust is added to the account by the author using a reference — c.f. #Openbadges + #Blockchains = #bitoftrust ?.

Using a ledger for badges allows the following operations:

• issuing a badge: add an entry to the ledger
• endorsing a badge: add a BitofTrust to the account associated with the entry
• revoking a badge: erase an entry in the ledger

Revoking badges raises an important issue: how to enforce the right to be forgotten — it might not look good on one’s profile to display lost badges? To preserve the right to re-inventing oneself, Bryan Mathers came up with an elegant solution: one’s personal ledger could actually be wrapped up as the genesis block of a new personal ledger.

Extract from my (future) Personal Ledger

Thinking of badges through a ledger is also a means to de-dramatise the question of self-issued-badges. While I’m a firm believer that they should play a more central role in the badge ecosystem, the current Open Badge infrastructure has made it impossible for the average user to issue badges, notwithstanding the criticism on the “value” of such badges for (hypothetical) employers… Creating a self-issued badge is nothing more than adding an entry to a ledger. Once created, it is possible to start collecting evidence and later ask for endorsements from members of the community.

What I have started to describe here is a Personal Ledger, a lifelong and lifewide inventory of my assets where “badges” are just assets among other assets — with one characteristic, probably shared with other constructs, which is connecting / cross-referencing other assets.

Overall description of the Blockchain-based Open Badge Infrastructure (BOBI)

The picture above provides a simplified representation of what a blockchain-based Open Badge infrastructure might look like. The blockchains are the records of the changes in the ledger. A user interface provides a meaningful display of the content of the blockchain in relation to one’s assets (e.g. a block will contain the book copyrights but not the book itself) and a number of services associated with the data contained in the ledger.

NB 1: while called a Personal Ledger, it does not mean that I can edit mine. Each change is done by adding a new block, an operation performed by other members (nodes) of the network — in the BitCoin world, the addition of new blocks to the chain is done by “miners” (most happens in China! — link).

NB 2: while in the bitcoin environment there is only one blockchain (for obvious reasons), there is no restriction to the number of blockchains that can run concurrently. So each Personal Ledger, could be represented by its own blockchain, each member of the network having a copy of all the blockchains — this could be optimised by distributing randomly “enough” copies of each blockchain, but that’s another story. On the other hand, there would be one blockchain for the BitOfTrust “currency.”

The blockchain is the federation

One of the issues discussed in the Open Badge community was the need (or not) for a “federation” of Open Badge storage:

We pack a lot of meaning into [the] open badges federation, what we really mean is “distributed badge storage that gives users choice and opportunity to be discovered for their achievements.” Federation means more backpacks, more user choice and more user benefit. (Chris McAvoy, 2014, source)

Without a federation, when I get a badge from Credly and want to put it into my Open Badge Passport, I have first to configure my Credly account to make it aware of my backpack (so, if I don’t have a backpack, I’m stuck), export my badges to the backpack, then go to my Open Badge Passport account to import them (with the hope that it will work). This is unwieldy and a federation of Open Badge storages would allow me to have one single view over all my badges.

The federation did not happen, and it is a good thing as there is a much better solution… which is… blockchains. When we will be using blockchains the Open Badge Factory, Credly and Badgr will have to use MY blockchain/ledger to issue the badges I have earned and when I am in my Open Badge Passport, Badgr of Credly account, I will have access to all my badges, disregarding which platform they were issued from. My blockchain is my passport/backpack and my passport/backpack is part of my Personal Ledger — the old backpack becomes a simple an entry in my Personal Ledger under which will be added everything that looks like a badge.

What other benefits?

Now that we have established that a Personal Ledger can be more than just an elegant solution to managing Open Badges, what else could we do with it?

One of the main benefits with blockchains is a clear separation between data (stored in the blockchains) and the applications serving/exploiting the data. The blockchain contains all the data from the whole network, which is a radical difference with today’s Open Badge infrastructure where the data is fragmented across the various badge issuing platforms (hosting assertions) and various storage platforms (hosting badges) — one of the consequences being the inability to know how exactly how many badges have been issued.

Having the data in a blockchain frees innovation, the same way the opening of public data does: the blockchain is the solution to opening up personal data while keeping full control over its exploitation. The blockchain is an invitation to create new applications and services from the wealth of data they contain. It is a serious threat to established trusts — watch out LinkedIn! Watch out Facebook!

A Personal Ledger is the record of the trust bonds we have established within the community. I can endorse a plumber or an electrician who can endorse me as a good client. Personal Ledgers could be used by the self-employed and voluntary workers to build their professional and social reputation.

Service and goods providers could use the information contained in Personal Ledgers to gain business in a novel way. Let us say that one of the services provided on top of the Personal Ledger is a mailing service. I could decide to only receive mail from people or entities I trust. So, if I trust ACME Ltd, I could endorse ACME ltd who then creates an entry in its Organisational Ledger. When ACME ltd wants to send information to its contacts it does it through the mailing service I trust that will check that I am in the ACME Ltd Organisational Ledger. When I don’t trust ACME Ltd anymore, I just withdraw my endorsement and no more mail will arrive.

The Personal Ledger is also a powerful metaphor for scaffolding learning: a learning plan could be translated into a series of entries in the ledger that have to be filled-in with evidence / proof of work. ePortfolio and personal learning environments (PLE) applicationscould be built on top of the blockchain. Learners would be fully autonomous from the information systems of institutions of formal education. A new generation of learning management systems could emerge, where learners would be in full control over their work and data.

What follows is an additional list of ideas rendered possible with blockchains / Personal Ledgers:

• The blockchain is the taxonomy: each time a badge is issued, it makes reference to criteria. Now imagine that when a new badge is created, through the user interface, the creator has access to all the vocabulary already used in previous blockchains. This could seriously reduce the number of redundant criteria and badges by displaying all the existing badges using a particular criterion group of criteria.
• The blockchain is open knowledge: imagine that someone creates a new badge describing emerging competencies related to new knowledge, e.g. data scientist, this could be valuable information for training bodies and employers.
• From search to discovery: with blockchains it should be easy to find all the people sharing the same badge (or collection of badges) while ensuring full anonymity. For example, someone willing to quit drinking could claim an AA badge in order to be discovered by the local chapter or another local AA badge holder.

Of course, what is described above is probably not optimal in terms of resources and processes. They are just intended as illustrations of things that could not be done before (with the current Open Badge Infrastructure) and are now made possible with the use of blockchains.

Summary and further questions

The objective of this post was to explore how blockchains could be used to implement Open Badges. I have tried to demonstrate that blockchains would not only be an elegant solution, but would allow the resolution of existing problems and open many opportunities.

If, for a moment, we accept the idea that blockchains are the solution to Open Badges Implementation, this raises a number of further questions:

• What body should be responsible for creating and maintaining this new infrastructure? The Badge Alliance is fit to maintain a standard, which is about documentation. With a blockchain infrastructure the business model would have to include software development and maintenance, scalable servers deployment etc. A whole new ballgame!
• What will happen to the legacy system? It should not be too difficult to write a programme transforming “pictures with metadata” into “Personal Ledger entries”…
• What consequences for existing businesses (issuing platforms) and what new businesses could emerge?

Looking forward to your suggestions, ideas and criticisms!

Many thanks for the discussions that contributed to formulating the ideas discussed in this post to (in alphabetical order) Bryan (including the picture!), Carla, Kerri, Ian, Nate, Sandro, Simone and Sunny.

Originally published at www.learningfutures.eu on December 14, 2015.

Openbadges + Blockchains = BitofTrust ?

One aspect of the question regarding a possible relationship between blockchains and Open Badges is to wonder whether the blockchain should be treated as some kind of add-on to the existing Open Badge structure/standard, or should Open Badges be integrated within a blockchain?

A starting point for an informed answer to this question is to do a simple test: take an Open Badge generated by one issuing platform and try to import it into another issuing/hosting platform. I have done this experiment recently, taking only a very small sample, and the results were rather… (un)conclusive — BTW, one suggestion for the Standards Working group would be to run a real life interoperability test (not just through a formal proof) across all platforms and publish the results.

Interoperability is a classical problem to which the ePortfolio community was confronted some years ago and to which no convincing answer was ever provided — the IMS-Global ePortfolio and Leap2A specifications (2 specifications for interoperability is already one too many!!!) are only used by a handful of ePortfolio platforms — notwithstanding that there are many ePortfolios that do not use any ePortfolio platform at all! Moreover, when we organised plugfests during previous ePIC conferences, we had to admit that 3 platforms using the same technical specification (IMS ePortfolio at the time) had problems understanding each other: exporting one ePortfolio from one platform then importing it to another did not always work properly…

One could have imagined that with a structure much simpler than ePortfolios, the problem of interoperability would have disappeared. It has not. And now that we have allowed extensions to the specification, the order of magnitude for potential interoperability problems has increased geometrically, not just arithmetically. Yet, the possibility to extend the specification, even by one single issuing platform, willing to gain a competitive advantage, with a better or innovative service, should probably be allowed. We certainly do not want a “one-size-fits-all” issuing platform. Innovation must go on!

Are blockchains the solution to Open Badges interoperability?

While the current Open Badge architecture has already demonstrated its limit to interoperability, is there a way to ensure that every possible badge issued by one party will always be 100% compatible with the hosting service of the receiving party? Could the blockchain be the answer to that question?

A blockchain-based architecture guarantees that when someone writes on the public ledger, the writing is legitimate and legible. There might still be problems with the content of the writing if those writing on the ledger do not respect the expected structure for the content (therefore we will still need something like a data model for Open Badges) but, at least, sending and receiving badges will always work, the blockchain specification guarantees it. The decision to accept or refuse a badge belongs to the ledger, and as there is only one ledger, it will not be possible to have a situation where a badge accepted by one platform is rejected by another. The public ledger is a means to enforce interoperability in real time and not post facto.

So, if we decided to move Open Badge metadata from “pretty pictures” to blockchains we are sure that at least the infrastructure will be working properly — not withstanding the numerous advantages provided by blockchains themselves.

From Open Badges to BitofTrusts

The whole process of sending and receiving badges can be extremely unwieldy, starting with the obligation to create a “pretty picture” — and if one is not a graphic designer, use paint-by-numbers-canned-badges clip-art to generate “ugly pictures” — I made some time ago the suggestion of the “one pixel badge” and it was a total flop! There must be a better mechanism. It is what I would like to explore now.

Imagine that every individual and organisation joining the Badge Alliance (or some other overarching body) receives 1,000 BitofTrusts to be distributed to entities they trust (people, organisations, services and things (Internet of Objects). Let us say that the distribution of trust is treated as a deposit (unlike bitcoins) that can be withdrawn when you do not trust one entity anymore. Now imagine that trust deposits generate interests in favour of the holder of the trust (the host of the deposit) that can be used to further trust other entities. We would have the basic components for establishing the foundations of a trust economy — which is a somewhat redundant expression considering that there is no economy possible without anticipated trust. To complete the description of the infrastructure, one would assume that every entity has a place to store trust deposits. Let us call it a Passtrust (it would be a wallet in the Bitcoins world, theOpen Badge Passport or Badgr in the current Open Badge world and the Backpack in the old model).

To refine the model further, we could add algorithms mimicking the behaviour of local currencies such as the Chiemgauer in Bavaria, where the capital looses part of its value if not spent during the year after being acquired, the objective being to have a currency used to facilitate the circulation of goods and services within the community rather than a means to hoard.

At this stage, we have simply defined a general trust mechanism that is not that different from an idiosyncratic local currency. In order to align Bittrusts with Open Badges, we need to define a mechanism to represent values, affiliations, achievements or competencies. Instead of a pretty (or ugly) picture, we could simply use entries in a public ledger: When an entity gives a badge to another entity, this entity adds an entry in the ledger and deposits a Bittrust — it doesn’t have to be a complete Bittrust; 1/1,000th or less would do the trick for establishing a trust link between an issuer and a recipient. For endorsement, instead of creating a new entry, a fraction of a Bittrust would be added to an existing entry.

NB: one advantage of this mechanism over the current revocation of Open Badges is that the revocation information will remain within the ledger instead of being erased from the infrastructure. And knowing that a trust bond has been revoked could be a very useful piece of information — that should probably be erased after a few years to avoid lifetime stigmas…

Of course, I realise that what precedes is a rather crude description that needs to be refined further through thought experiments as well as mathematical and computational models — something we have not judged useful for the current Open Badge Infrastructure so far. The idea of giving everyone 1,000 BitofTrusts is just one option among many — it could be a certain amount each year, some entities might have the right to produce BitofTrusts and give them, not just as a deposit. I like the idea of having the trust others have in one entity generates interests in favour of this entity as it would be a tangible representation of the benefits of being trusted, but I am certain that there are other ways to achieving similar results.

All I wanted to achieve with this post is open a conversation, using blockchains as a “tool to think with,” opening new horizons for establishing a resilient, trustworthy, open and distributed Open Badge Infrastructure.

I am looking forward to your comments and criticisms.

NB: changed BitTrust to BitofTrust after publishing the next blogpost.

Originally published at www.learningfutures.eu on November 25, 2015.