Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Endorsements of Open Badges with blockchain technology

 

This short document marks the final deliverable from Coinversable B.V. to SURF for the proof of concept in which we have shown that blockchain can be used to store endorsements of Open Badges. We have extended Badgr (forked from Concentric Sky) with functionality to communicate with the open-source Validana.io blockchain.
Along with this document repositories with readme.md and source files have been delivered to SURF. All code written by Coinversable for this PoC is available under the AGPLv3 license as requested by SURF. On a later notice Coinversable will also commit / merge the endorsement code to a Git repository provided by SURF.

 

Table of Contents

DEMO and walkthrough

As part of the final delivery Coinversable has installed a fully working version of Educhain on a server hosted by SURF. With the following credentials you can login as admin on the demo website.
https://dev.educhain.nl.

...

A specific badge can also be endorsed. Please navigate to the specific badge and press the red button to endorse. An endorsement of a badge can not be withdrawn as per specification.

 

Architecture

 

This picture provides a schematic overview of how educhain works

 

The badgr-client and badgr-server packages were forked from concentric sky. The badgr-server was left untouched within the educhain development. This means that all transactional logic with the blockchain is done from within the client, from within the web browser of the end user. This provides us with two mayor benefits. Firstly we are instantaneous compatible with all existing badgr-server installations. Secondly, private keys used for signing transactions will never leave the web browser of the client.

...

We have shown that blockchain can successfully be used with Open Badges in the educhain PoC. However before we can go into production or even into a real-life pilot with universities we suggest a few enhancements. This list is not exhaustive and possibly there are more user features.

Validation service
The validation service can be extended to also show which endorsements there are on the blockchain.

Endorsements with data
The blockchain currently only stores which entities endorsed which ID’s of badges / badge classes. Better would be to follow the specification on endorsements and also allow extra information such as a descriptive field. We could use hashing to prevent privacy sensitive information from landing on the blockchain, whilst maintaining the ability to prove that the badge class and metadata were in deed unmodified.

Timeline
When an entity endorses a badge class, and later withdraws that badge class, no ‘history’ is shown in the Badgr environment. Therefore if a student obtained a badge from an endorsed badge class, and the endorsement is withdrawn, one can not easily verify that the badge class was indeed endorsed at the time of acquisition. It would be convenient for the student to prove that the badge class was endorsed at that point in time via the user interface. Now you have to become a node and use the blockchain ledger to prove it.

History of names
SURF is able to change the name of an educational institute by submitting another request to add an institute for the same public address. This only changes the human friendly name on the blockchain. However we can expect end-users to not check the public addresses of the institutes themselves. Therefore it would be wise to show which previous names were used for a institute. The same holds for educational entities, which change name often.

Roles / permissions via blockchain
In the current PoC there already is a chain of trust on the blockchain, namely SURF -> Institute -> Entity. We could extend this functionality to also store on the blockchain which participants can be an issuer in badgr. For instance we could allow everyone to be able to create an issure, but display a ‘green lock’ icon next to the issuers which are inside the chain of trust. Or we simple disable the functionality in Badgr entirely when the user does not have the right permission on the blockchain. This functionality would be similar to the ‘endorse’ and ‘withdraw’ buttons currently found in the UI.

Signed badges
With blockchain everything is signed. We can use this to also sign badges and badge classes. If implemented well it would make it possible for organisations to check the validity of a badge without having to use the validation service. This way badges are verifiable even if the university website / validation service is offline.

Identity and Key management (badges without email addresses)
The current PoC does not help end-users with storing their Private Key. We could extend the PoC by allowing SURF or the university to manage the private keys. This functionality is optional. If the user wants to keep his own private key we can ‘transfer’ (new smart contract) all badges of the old user to the new user, via a three way signature (old account, university, new account). We should then provide the public address of the user in the badge recipient field, and the user can transfer badges after he left the university to a new account.

Store everything on the blockchain
We could create a version of the badgr-ui where all information is stored on the blockchain. Therefore the badgr-server package would become entirely obsolete. We should then rethink the definition of an account within badgr-ui, and create a possibility for end-users to allow a third-party (surf, university, DUO) to store their private key if preferred. Also everything would be stored on the blockchain. We should identify which information is private and which can be made public. We can also keep a simple local database and place hash values of privacy sensitive information on the blockchain. Upon validation the hash is calculated and checked with the blockchain.