From blockchain to BadgeChain (3)

June 6th, 2016 | Serge Ravet

In the previous post we added to the Open Badges’ DNA its first genes extracted from the blockchain. We obtained the following results:

  • Everything can be represented as a Badge — everything is relationship;
  • A BadgeChain is made of chained badges (not yet a blockchain);
  • A BadgeChain is a like a distributed database: badges are stored all over the Internet.
  • New objects can grow organically from the aggregation of badges in the BadgeChain — e.g. ePortfolios.

There are two points we have not addressed yet

  • How is the BadgeChain practically stored?
  • How can we trust the content of the BadgeChain?

The trustworthy BadgeChain

Can we check whether the components of the BadgeChain, Open Badges, are authentic (the issuer is the issuer, the earner is the earner, etc.) simply by looking at them, just as we would do to check whether a banknote is counterfeit? The answer is yes, and the means to do it is named cryptography. Here are the conditions to create badges that resist effective counterfeiting:

  • Every participant in the network uses one or more public / private key pair;
  • The public keys are used as the identities of the participants in the network.
  • The private keys are used to encrypt information that can then be deciphered using the matching public keys.
  • Reciprocally, the private keys are used to decipher any information encrypted by the matching public keys

The picture below illustrates the process when Alice creates a badge containing the information that will be used to verify whether it is authentic or not.

How to create trustworthy badges using cryptography?

What happens when Alice creates a badge:

  1. For practical reasons (saving space and time) the content of the badge created by Alice is transformed into a digest, a small and unique representation of the complete badge using a public algorithm called hashing. It is as impossible to reconstruct the original badge from its digest, as it would be to rewrite an article from its summary.
  2. A signature is computed from the badge’s digest using Alice’s private key which is then added to the badge.

How the integrity of the badge and whether Alice is the issuer are checked:

  1. A digest of the badge is computed with the same hashing function used by Alice.
  2. The signature of the badge is deciphered using Alice’s public key which is provided by the Issuer metadata of the badge. The result should be the digest initially created, before being encrypted by Alice’s private key.
  3. If the two digests are different, then we can conclude that the badge is counterfeit.

Without entering into the details of cryptography, one of the properties of this kind of encryption is that it is not possible from the knowledge of public information (the public key, signature and digest) to guess what the original private key is. It is practically impossible for anybody but Alice to create a badge where she is declared as being the issuer — at least until quantum computing becomes a reality!. The down points of cryptography are that the private key must remain an absolute secret and must not be lost as it cannot be recreated (but you can save several copies in different safe places!).

The private key can be used to create one or more receiving badges, i.e. badges that will appear as the actual earners of the earned badges. This way one public/private key pair can be used to create multiple identifiers which are used to collect different types of badges.

Alice creates 2 badges as IDs to collect different types of badges

Furthermore, Alice can create multiple public/private key to keep her different identities totally separate — in the example above, the two badge identifiers make reference to the same public key, so the identities can be associated without any effort.

How is the BadgeChain stored?

To connect a badge to another badge, badges need to have an address (or an identifier that can be translated into an address) where they can be found. When Alice creates Alice 1 and Alice 2, the two genesis badges that will be used to aggregate future badges, they could be stored anywhere on the web. Alice could decide that all the badges she receives will be stored on her blog, so the location of her first genesis badge could be something like http://www.aliceblog.me/badges/alice1.png. When Bob wants to issue a badge to Alice, he can then use this address as the earner of that new badge.

Alice can then decide to store the new badge earned at http://www.aliceblog.me/badges/badgeorange.png. At a later stage if someone else wants to endorse the orange badge, the endorser will use http://www.aliceblog.me/badges/badgeorange.png as the earner of the badge.

Badges directly accessible with a URL

While this seems to work, in fact it does not. Let us imagine for a moment that Bob issues a first badge to Alice, then for whatever reason wants to endorse the badge he has just issued, how could he know the address before Alice has stored the badge? And when she has stored the new badge, how could Bob know its address?

The solution to this problem is twofolds:

  • every badge is identified by a unique identifier or UID
  • there is a means to translate a UID into a real address

For the sake of the demonstration, let us assume that each badge’s signature is unique, we could keep a table with two entries: the signature of the badge, and its real address. When we want to access the content of a badge, we look in the table for the signature to find the real location of the badge. If the holder of the badge wants to move the badges to another location, the entry in the table is changed — and if the earner wants to hide the badge, the address is erased.

A similar mechanism is used on the web to locate its content. For example, the identifier of my blog is learningfutures.eu, which is associated to the IP address 108.178.52.174. The translation of the string of characters (learningfutures.eu) into the real address on the Web is performed by a Domain Name Server or DNS. If tomorrow I decided to move my blog to another server with another IP address, I would just have to notify the DNS of the new address, and people would be able to continue to read my blog as usual.

Badges real addresses are saved in a shared table that is updated when a badge is moved

Let us call our (free) interpretation and application of the DNS mechanism to Open Badges a BNS or Badge Name Server. A BNS has several interesting features:

  • The issuer enters the UID on creation of the badge — the UID column can only be written by issuers.
  • The earner provides the real address of the badge after it has been accepted and stored — the real address can only be written by the earners of a badge.
  • The earner can change the address of a badge (to move badges to other locations) or erase it.
  • multiple copies of the BNS can be distributed among the members of the network and are synchronised by applying certain rules.

The table of the BNS could be improved by providing for each UID (the signature in our demonstration) a column with the issuer and the earner of the badge, making it easy to retrieve all the badges associated to an earner or an issuer. To revoke a badge, the badge issuer would notify the BNS to erase the entry matching the UID of the badge — after checking the authenticity of the issuer! To take into account the possibility that a badge might have been revoked, the verification mechanism of the badge integrity would start by checking that the signature of the badge is still in the BNS. If not, it would mean that the badge has been revoked.

If erasing an entry in the BNS might not seem enough to effectively revoke a badge (would not it be better if we could erase the badge altogether?) in reality it is perfectly sufficient as the original earners are facing the following dilemma:

  • If they keep a copy of the badge, any person displaying the badge will see that it has been revoked
  • If they erase all the copies of the badge, nobody will ever know that they once had this badge and that it is now revoked

Similarly, we cannot forbid people to create badges that would not pass the integrity test (e.g. using the public key of an issuer that is not themselves) and store those faked badges anywhere on the Web. While legal action might be sometimes necessary, once everybody understands that the only valid reference for the integrity of Open Badges is the BNS, fake badges should not have a negative impact on the trustworthiness of the BadgeChain ecosystem —as they will not be part of it. Web crawlers should be able to discover where undesired and faked badges are stored.

What have we achieved at this point?

We can create trustworthy BadgeChains that can be moved around the web. A table distributed among the members of the Open Badge ecosystem (the BNS) maintains the integrity of the BadgeChain including the revocation of badges.

There are still problems to address, in particular: as the badge earners are responsible for storing their badges, problems would arise if their storage crashed and did not have a backup to restore them — a problem unknown to blockchains with their distributed ledgers!

We still do not have a fully functional blockchain, but we are getting closer.

From blockchain to BadgeChain (2)

June 6th, 2016 | Serge Ravet

In the previous post, we looked at the relationship between trust, Open Badges and blockchains. To paraphrase George Bernard Shaw, one could say: Open Badges and blockchains are two technologies separated by a common idea [trust].

To explore how Open Badges and blockchains could merge into a new technical object, my reasoning will pass through several stages. We will start with a BadgeChain that does not make any reference to the blockchain technology, then, step by step, we will describe the mutation of this initial object through the incorporation of new genes into its DNA — hoping that we will not have created a chimera!

BadgeChain take one: everything is a badge

To create something that looks like a BadgeChain, we need to link badges together; there are multiple ways this can be achieved:

  • Indirectly: badges are “connected” through each individual issuer and earner. The issuer is a kind of “connector” between all the badges issued (and their earners), the earner is a kind of “connector” between all the badges received (and their issuers). Badges can also be connected through the alignment metadata, a list of objects describing educational standards — a property of the version 1.5 of the standard that has not been widely exploited.
  • Directly: badges are literally linked to other badges. For example, an endorsement badge could use the address of the badge being endorsed as the identification for the earner of that badge.
An endorsement as a connected badge

As a chain invokes the image of a direct connection between its constituents, we will focus our attention on creating an environment where everything is a badge. There is a legitimate reason to use badges for everything: once we understand that a badge is a relationship (between an issuer and an earner), saying everything is a badge is not different from saying everything is relationships. Making everything a badge should make it as easy to play with them as it would be with Lego™ blocks.

NB: while I often use the Lego™ metaphor to describe the simplicity of Open Badges and how it makes it possible for educators to practice bricolage, if I am honest, in the depiction of the state of the badges as a Lego blocks, I should write:

  • it is not possible to plug them together: square tubes do not match round studs (there are also oblong studs on half of the top and half the bottom is flat with no hollow parts)
  • if you insist on building something with them, do not sneeze, or you’ll have to restart from scratch!
  • when you discover that there is not much you can do with them, you read the manual and understand why there was a bag, a kind of backpack: it’s to carry them with you wherever you go to show your collection, to a[n] (probably uninterested or condescending) audience…

The next Open Badge standard should bring us closer to the conditions for Lego™ block-like badges, with matching tubes and studs. This should open the Open Badge ecosystem for some serious and rich play to take place (*).

In a world where everything is a badge, we could use badges for many different purposes: creating personal identifiers, linking to evidence, setting criteria for issuing or receiving a badge, etc. Some of these options are described in the table below.

Everything is a Badge
Everything is a Badge

In the picture above, the arrows elicit the links between the components of a badge. The green and purple badges are identifiers with the green badge being self-issued (self-referential). The Issuer of the yellow badge at the centre is the purple badge so the content of the Issuer metadata of the yellow badge contains the address of the purple badge. The Evidence metadata links to a blue badge that was issued by the issuer identified by the purple badge — it could be an observation of the learner’s performance, and the Evidence of the blue badge could be a video of the observation and the Criteria the narrative of the observation by the issuer.

There are probably better ways to connect badges together, but what we want at this point is not to decide on what is the best possible way to connect badges together but to explore the properties of chaining badges together: what are the properties of chained badges that badges placed in a bag do not have?

The properties of chained badges

Chained badges change the topography of the Open Badge landscape where issuers are currently at the summit of their Open Badge dominions. Chained badges are a means to put an end to the strong asymmetry between issuers and earners implemented in the original version of the Open Badge Infrastructure — surreptitiously underpinned by the formal education credentialing model.

By connecting badges together, we are creating interwoven threads of data, so starting from one person’s identifier in the network we are able to follow multiple paths that connect this person to all the other participants in the network, their relationships, knowledge and the artefacts produced. Chained badges create one global distributed database from where one can pull different threads, creating multiple narratives, from different points of view: individual, community, organisational, city and region.

Moreover, when looking at the picture above, we are looking at something that might speak to the ePortfolio practitioner. By connecting together pieces of information we are creating meaning and assembling the elements of a new artefact: a portfolio. Most of us are familiar with the action verbs associated with ePortfolios: collect, select, connect, reflect — BTW, those verbs do not describe a “sequence” as the collection could be the result of a reflection and conversely! Open Badges are a means to simultaneously collect and connect, while creating meaning providing the fuel for further reflection (and action!).

Until now, the understanding of the link between ePortfolios and badges is dominated by ePortfolios as a place to display Open Badges and the use of ePortfolios to earn a badge — this is particularly clear when practitioners oppose ePortfolios and Open Badges or see them as “complementary.”. In this perspective, the link between ePortfolios and Open Badges is mainly functional, not organic; they are treated as two different objects.

bee-badges for hive-portfolios

My proposal is that Open Badges and ePortfolios are not “complementary” loosely connected objects , but Open Badges are the substratum from which ePortfolios can grow organically, like a beehive out of the activity of the bees — bee-badges for hive-portfolios!

By providing a space where everything is a badge, we have also resolved the issue of interoperability: we render obsolete standards like IMS ePortfolio (hardly used) and LEAP2A (slightly more used) that are based on a fragmented vision of information systems, in particular the storage of data, something that is now challenged with the increased adoption of distributed ledgers (blockchains).

(*) Nate Otto commented on this point: “the Learning Pathways data vocabulary allows a data format that enables this. See https://usecanvas.com/ottonomy/learning-pathway-models-api/47JdBeSCqzKJ1v3H8Oswlo — which shows some “report style” syntaxes using this proposed vocabulary. The context is not build yet, but it is a data model that allows us to build nested hierarchies of the legos, and then to each lego, you may specify a relationship to suggested badges, earned Badge Assertions, etc.”