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.

Blockchains vs OpenBadges (“blocks without chains”)

Last Thursday, as I attended a meeting at the old Paris stock exchange (palais Brogniard) with people working on blockchains to discuss the Open Badge Passport, what did I discover? A number of the ideas we wanted to develop with the Open Badge Passport (as services exploiting the content of badges metadata) were already in full development using… blockchains, not Open Badges. That was some reality check! The following morning I read Certificates, Reputation, and the Blockchain (link) where Philipp Schmidt, from the MIT Media Lab, explains how they are moving from paper certificates to blockchains after a short encounter with digital badges…

Issuing a certificate is relatively simple: we create a digital file that contains some basic information such as the name of the recipient, the name of the issuer (MIT Media Lab), an issue date, etc. We then sign the contents of the certificate using a private key to which only the Media Lab has access, and append that signature to the certificate itself. Next we create a hash, which is a short string that can be used to verify that nobody has tampered with the content of the certificate. And finally we use our private key again to create a record on the Bitcoin blockchain that states we issued a certain certificate to a certain person on a certain date. Our system makes it possible to verify who a certificate was issued to, by whom, and validate the content of the certificate itself.

Suddenly Open Badges seemed to have regressed from a technology that could conquer the world to a parochial technology solely at the service of the great priests of education spraying badges like papal indulgences so their parishioners could join the heaven of employment… one day… if their prayed with enough fervour.

I will not go into details, but my observation over 30 years of a number of attempts at combining “education” and “technology” into one thing called “educational technology” resulted (most of the time) in impoverished education and impoverished technology — which is very different when education meets general purpose technology and add to each other. I would love to be proven wrong, but what is the technical innovation, born within the premises of education that has had any value outside? Apart from Facebook (and Open Badges, one day?) I cannot recall any.

Innovation (technical and social!) happens outside of the world of formal education. If innovators choose to use blockchains and not Open Badges to produce services based on trust relationship, then it is probably a sign that we should rethink the badge technology and its infrastructure altogether — or promote Open Badges as an alternative to blockchains!

A few months ago, Doug Belshaw wrote a post on Peering Deep into Future of Educational Credentialing (link) where he explored how Open Badges and blockchains could be connected.

While we wouldn’t want to entirely remove the “human” element around credentialing, a hybrid OBI and blockchain approach could add value to our current system. Machines and software are extremely good at fact-checking, whereas humans are good at meaning. We need both.

At the time, I asked Doug to explain the benefits of blockchains over signed badges (which is one way to make them verifiable). When I look at today’s explosion of innovations based on blockchains and compare it to innovations based on Open Badges, there is a clear advantage in favour of blockchains.

Some of the innovations based on blockchains:

• D-CENT (Decentralized Citizens ENgagement Technologies) a Europe-wide project to create digital tools for direct democracy and economic empowerment (link)
• BitBeat, a social network (like Instagram) (link)
• La`Zooz synchronises empty seats with transportation needs in real-time, matching like-minded people to create a great ride-sharing experience for a “Fair fare” (link)
• Storj (pronounced: storage) a cloud storage platform and suite of decentralized applications that allows users to store data in a secure and decentralized manner. It uses blockchain features like a transaction ledger, public/private key encryption (link) — much better than a backpack!

For a longer list of potential domains where blockchains could be used read the annex.

What I would like to elicit is, if we compare the breadth and number of innovations enabled by blockchains with the breadth and number of innovations enabled by Open Badges, we might just want to decide to reinvent Open Badges from the blockchain (some already do!).

As one of the winners of the DML Trust challenge, we planned to use Open Badges to create something truly innovative: a bottom-up trust architecture enabling a new generation of services exploiting badges metadata. We are now almost half way, the first version of the source code is in the process of being released, and I now wonder how should we go for the second half. Can we just go on ignoring the promise of blockchains of a fully symmetric trust infrastructure (something we have failed to achieve so far)?

What do Open Badges and blockchains have in common? Bottom-up Trust!

In a previous post I suggested the idea of “the one pixel badge.” Blockchains are the means to have “the zero pixel badge.” Using a picture to store metadata was a genius idea and we should be grateful to those who came up with it. The problem with this genius idea is that it took on an entirely different meaning in the heads of the not so genius. The picture, that was just a convenient vehicle for hosting a set of metadata, became the central element. Efforts were made to create badge editors (to create “pretty pictures”) but not a single development has been engaged in developing a proper criteria editor (using linked data / RDFa to create machine readable criteria). As long as the picture is pretty, if the content is dumb (i.e. with no semantic value) it should not be considered a problem…

The main problem with the “pretty picture” is that it hides to most the fact that a badge is a trust relationship between two parties, which is precisely what a blockchain is about! The major problem with the Open Badge Infrastructure (OBI) is that we have not been able yet to create chains of trust and networks of trust (although it is one of the goals of the Open Badge Passport).

Open Badges = blocks without chains

Therefore, when I look at Open Badges and compare them with blockchains, I am tempted to describe them as “blocks without chains.”

I must state that this description does not do justice to the great work done with “linked data” in the new Open Badges specification (1.1). Exploiting the power of JASON LD (linked data) the new specification provides “chains.” My question is: how much effort would be required to make Open Badges, or rather P2P credentials (with JASON LD, no need for a “pretty picture”) a viable general purpose technology that could compete with blockchains?

What was wrong in our initial attempt at connecting Open Badges with blockchains? Currency!

My understanding of the initial discussion on blockchains and Open Badges was veiled by discussions on Open Badges as “new currency” (how to “monetise” badges?) and Bitcoins being the “new currency.” I replied earlier that the “true currency” of Open Badges is “trust” and that it is probably the oldest currency ever. I did not see the need to use something like Bitcoins to represent this currency when Open Badges already had this trust relationship embedded. Why change a technology that works?

Moreover I thought that badges were probably “greener” as they do not require the huge computing power Bitcoins need for “mining” (i.e. enforcing contracts). And if the value of a Bitcoin is inherently wrapped up in its rarity, then it violates my principles and those of a knowledge economy where value is unlimited. My mistake was to restrict my understanding of blockchains to Bitcoins. They are so much more than that!

What is wrong with the Open Badge Infrastructure? The Backpack!

Mozilla recently decided to fund the improvement of the backpack (an idiosyncratic silo where Open Badges can be hosted with the hope that someone might be interested to see them, one day, after pushing them to LinkedIn and Facebook) when the only reasonable thing to do would have been to get rid of it altogether.

Open Badges and blockchains are both about trust. What makes blockchains powerful is the ability to create a fully trustworthy infrastructure without any super-authority or having one party more trustworthy than any others.

One of the arguments I heard for continuing the Mozilla Backpack was “Mozilla is an organisation that can be trusted.” As Kerri Lemoie noted aptly, Mozilla could not be trusted for a while, simply to maintain the service, a duty that includes correcting bugs. But there is a more fundamental reason why we do not need to have a backpack hosted by Mozilla: in a blockchain ecosystem, there is no need for a super-trusted entity like Mozilla to protect the interests of the badge owners.

The Badge Alliance and the Open Badge specification is what is needed to protect the interests of the community.

A bottom-up trust ecosystem can be built without the need of a surrogate parent! The Mozilla foundation has done great things and will continue to do so, but “improving” the backpack is probably the worst signal that could have been given to the community. It might please those who want to keep Open Badges within a disconnected silo — which it is — something “just for educators.” The Badge Alliance and the Open Badge specification is what is needed to protect the interests of the community.

“improving” the backpack won’t change this annoying fact an iota [asymmetry].

I keep repeating that the Open Badge Infrastructure is deeply asymmetric (blockchain architectures are symmetric!) and “improving” the backpack won’t change this annoying fact an iota. Migrating the OBI to a blockchain infrastructure might be a better investment if Mozilla really cares to deal with solving bugs. The most serious one in its architecture: asymmetry!

And now?

Considering that Open Badges are:

• a trust relationship (contract) between two parties (individuals, organisations, services, etc.) — P2P credentials
• verifiable — while preserving anonymity
• revocable — according to contractual rules
• actionable — to open a door, access content, etc.

My suggestion is to explore the feasibility and value of implementing a blockchain-based Open Badge Infrastructure by addressing (in parallel) the following questions:

1. What current issues could be solved with blockchains?
2. What current issues could not be solved with blockchains?
3. What new issues would emerge from a blockchain-based OBI?
4. What new opportunities would emerge from a blockchain-based OBI?
5. What are the pros and cons of a blockchain-based OBI vs. the current OBI?
6. Could a technology derived from Open Badges (or another technology) offer a viable alternative to blockchains in their current applications?

Your inputs are welcome!

Annex: The Mega-Master Blockchain List

I. Financial Instruments, Records and Models

• Currency
• Private equities
• Public equities
• Bonds
• Derivatives (futures, forwards, swaps, options and more complex variations)
• Voting rights associated with any of the above
• Commodities
• Spending records
• Trading records
• Mortgage / loan records
• Servicing records
• Crowd-funding
• Micro-finance
• Micro-charity

II. Public Records

• Land titles
• Vehicle registries
• Business license
• Business incorporation / dissolution records
• Business ownership records
• Regulatory records
• Criminal records
• Passports
• Birth certificates
• Death certificates
• Voter IDs
• Voting
• Health / Safety Inspections
• Building permits
• Gun permits
• Forensic evidence
• Court records
• Voting records
• Non-profit records
• Government/non-profit accounting/transparency

III. Private Records

• Contracts
• Signatures
• Wills
• Trusts
• Escrows
• GPS trails (personal)

IV. Other Semi-Public Records

• Degree
• Certifications
• Learning Outcomes
• Grades
• HR records (salary, performance reviews, accomplishment)
• Medical records
• Accounting records
• Business transaction records
• Genome data
• GPS trails (institutional)
• Delivery records
• Arbitration

V. Physical Asset Keys

• Home / apartment keys
• Vacation home / timeshare keys
• Hotel room keys
• Car keys
• Rental car keys
• Leased cars keys
• Locker keys
• Safety deposit box keys
• Package delivery (split key between delivery firm and receiver)
• Betting records
• Fantasy sports records

VI. Intangibles

• Coupons
• Vouchers
• Reservations (restaurants, hotels, queues, etc)
• Movie tickets
• Patents
• Copyrights
• Trademarks
• Software licenses
• Videogame licenses
• Music/movie/book licenses (DRM)
• Domain names
• Online identities
• Proof of authorship / Proof of prior art

VI. Other

• Documentary records (photos, audio, video)
• Data records (sports scores, temperature, etc)
• Sim Cards
• GPS network identity
• Gun unlock codes
• Weapons unlock codes
• Nuclear launch codes (!)
• Spam control (micro-payments for posting)

Source: http://ledracapital.com/blog/2014/3/11/bitcoin-series-24-the-mega-master-blockchain-list

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