For a long time I have played with the idea of picture-less badges and one-pixel badges. The reason for that was the over importance attributed to what I often refer to as the “pretty picture” playing the proverbial role of the tree hiding the forest of trust. Picture-less badges and one-pixel badges force us to reflect on how to get value out of the metadata embedded in a badge: what can we do with a badge if we don’t have a “pretty picture” to display?
One of the most disheartening and yet fascinating thing with Open Badges is our inability (or lack of interest) in using them to inform even the most elementary service related to badges. For example, I remember very clearly a session during my first visit at the Mozfest in 2012 where the idea of “badge the badger”was discussed, i.e. use badges to control the right to issue certain badges. Four years later, nothing has changed. For an external observer, that could be interpreted as if we do not really believe in their value beyond displaying “pretty pictures.”
Thanks to the work done with the 2.0 spec, things might change, but change will not happen solely with the publication of a new standard: to exploit its full potential we need the right technology and, moreover, the right mind-set. Using Open Badges as verifiable claims to control access to services could have been done with the current version of the standard. If it has not happened, it is not primarily the fault of a defective standard, but the mind-set of some of those involved in the Open Badge ecosystem, in particular the excessive focus on badges as micro-credentials rather than verifiable claims.
The other element in my reflection is the issue of endorsement, another key feature of Open Badges that have still not been implemented. When thinking of it, issuing a badge is a form of endorsement: the earner represented by an identifier (an email address in the original standard) is endorsed by the issuer of the badge for the things described in the criteria and supported by the evidence (link) embedded in the badge.
endorse |ɪnˈdɔːs, ɛnˈdɔːs| (US & Law also indorse)
verb [ with obj. ]
declare one’s public approval or support of: the report was endorsed by the college.
sign (a cheque or bill of exchange) on the back to make it payable to someone other than the stated payee or to accept responsibility for paying it.
late 15th cent. (in the sense ‘write on the back of’; formerly also as indorse): from medieval Latin indorsare, from Latin in- ‘in, on’+ dorsum ‘back’.
Thinking of badge issuing as a form of endorsement suddenly made it clear that we could rethink the badging process as a series of endorsements. And if we imagine that an endorsement should be as easy to perform as signing a document, then we might consider simplifying and extending the badge issuing process as a workflow of digital signatures capturing the different levels and types of endorsements.
This is what this post is exploring.
Towards flexible Open Badge workflows
When thinking of it, what we are doing with Open Badges is literally writing on the back of a picture:
- the creator of the badge creates a picture then writes the Title and the Criteria (and conditions for delivery in the next specification)
- the issuer adds the Issuer’s identifier and Earner’s identifier
- the earner adds Evidence
- the ‘endorsers’ add Endorsements
While the sequence above is the usual workflow, there is no reason to have this particular sequence to obtain a well formed badge:
- the creator of the badge produces a picture then writes the Title, Criteria and Conditions
- the earner adds the Earner’s identifier and Evidence
- the ‘endorsers’ add Endorsements
- the issuer adds the Issuer’s identifier
This sequence would make sense when someone is committing to earning a certain badge, collects evidence and endorsements for the work/learning performed to eventually be accredited. In this use-case, the badge exists before being issued in the sense of the current Open Badge Infrastructure.
This leads to the following remark: the way we use verbs for Open Badges tends to be the very same as for traditional credentials. With traditional credentials, the paper diploma isissued after the final assessment. There is no such thing as a diploma issued before the final assessment. What we have currently implemented as Open Badge process is a carbon-copy of the traditional credentialing workflow.
Yet Open Badges should offer alternatives to the traditional credentialing workflow and let learners claim a badge then work towards satisfying the criteria by collecting evidence and endorsements. In that case, a badge can be issued to be accredited at a later stage. Learners should be also free to create their own badges and ask for endorsement, including some form of accreditation at a later stage.
Possible meanings in relation to the presence of identifiers
If we use digital signatures as a means of identification (c.f. next section), the workflow of someone working towards a badge could be described as follow (c.f. picture below):
- The earner claims a badge
- The badge is issued by a badge platform
- The earner signs the badge
- The earner adds evidence (artefacts, testimonials, etc.)
- When ready, the earner submits the badge to an accreditor
- The accreditor signs off the badge
- To keep the badge current, the earner collects endorsements —endorsers add their signatures to the badge.
The different stages when working towards a badge
Of course, I do not claim that all badge workflows have to be like this one, but there is no reason to make it difficult for the members of the Open Badge community to implement such a workflow if they wish so.
To support this kind of flexibility, two main approaches are possible:
- Within individual Open Badge issuing platforms —the Open Badge Factory is working actively to provide this kind of flexibility, e.g. with peer-reviewed badges
- By building an architecture based on digital signatures and verifiable claims — and be independent from the idiosyncrasies of each badge platform
It is this second option that is explored in the next part of this post.
From Open Badges to Open Signatures
As mentioned in the introduction to this post, looking at the badging process as a series of endorsements opens interesting perspectives. The first one is to move the process of endorsement from ancillary to Open Badges, some kind of add-on, to a process in its own right that could be used with any digital objects, not just badges, for example to endorse evidence submitted to earn a badge, but also to endorse someone, an idea, a document, etc.
If a badge can be seen as the endorsement of someone by another entity (person or organisation) for certain qualities described in the criteria, we could imagine other means to convey the same kind of information: for example adding a statement with the criteria in a document belonging to the endorsee then signing the document containing this new statement, as one could do with a physical document.
The way to do it is described in the picture below:
- The endorser and endorsee are identified by their public keys
- The private key of the endorser is used to encrypt the document and the statement
- The endorsement is attached to the document. It contains both public keys and the encryption of the document+statement using the endorser private key.
Endorsement of a document
In the example above, a document is being endorsed. Replace this document with an Open Badge and you have put in place the mechanism for endorsement and accreditation, the latest being nothing more than the endorsement by the authority who has special rights in relation to the badge — what we currently call issuing rights.
The picture below displays the complete workflow of a badge issued by an awarding body, up to the endorsement after accreditation. At each stage of the process, the party involved adds its signature to the badge, starting with the badge designer.
An extended signature workflow
The badge is a container where Title, Criteria, Evidence and Signatures are being stored. When they add their signatures to a badge, the creator, assessor, verifier, issuer, earner and ‘endorser’, ‘endorse’ the badge in their own capacity. Adding Signatures is what makes the badge progress from one stage to the next, then keep the it current.
One conclusion we can infer from this is that the main function we need for delivering badges and keeping them current (by adding new endorsements) is the ability to sign badges.
What makes the badge ‘issued’ in the sense of the original badges is the fact that it is signed-off by an entity that is accredited to sign-off the badge in the capacity of accreditor. And to do so, we simply have to implement a policy enforcement point in the issuing platforms: to sign-off as accreditor, the platform checks that the accreditor has the credentials as described in the original badge class, what we earlier called Conditions. And to verify if a badge is valid, a verification service can check that the entity who signed as accreditor matches the conditions defined in the badge class.
Differentiating between the different types of ‘endorsements’ is just a matter of protocol. For example, we could decide that a badge class will contain conditions for endorsing a badge as ‘accreditor’ or ‘assessor’: in order to accredit badge XYZ, one needs to have “Badge Accreditor XYZ.”
Parapher: the technology for Open Signatures
Once we agree that the main process involved in badging is a series of endorsements, and that endorsements can be performed using digital signatures, we have the following choice:
- Building an idiosyncratic endorsement mechanism, just for Open Badges; or
- Building a general purpose endorsement technology that could also be used for Open Badges.
The alternative is what we have the right to call a no-brainer. Building a general purpose endorsement technology is probably not more difficult to develop than an idiosyncratic one. And it would provide the advantage of simplifying the Open Badge architecture, making it a particular implementation of a more general idea.
Let’s call this general purpose technology a parapher, i.e. a means to add one’s digital signature to any digital object.
a flourish after a signature, originally as a precaution against forgery.
late Middle English (denoting a paragraph): from French paraphe, from medieval Latin paraphus (contraction of paragraphus ‘short horizontal stroke’).
A parapher is nothing more than a tool to manage public/private key pairs, something that the blockchain wallets provide to their users. One of the great lessons learned from blockchain adoption is that we have been able to overcome most of the difficulties linked to the implementation of a public key infrastructure (PKI). While it is still at an early stage and we need to gain more experience on how to deal with issues like losing one’s private key, infrastructures based on asymmetric encryption do work (c.f. Bitcoins and many other blockchain initiatives)!
By providing everyone with a parapher, we would be able to:
- Sign/Endorse Open Badges in one’s own capacity (creator, assessor, verifier, issuer, earner, endorser, etc.)
- Sign/Endorse evidence used in a badge submission
- Sign/Endorse a comment
- Sign/Endorse a document, a person, a business, a campaign, etc.
While there are (still!) discussion on whether people should have the right to issue their own badges, I can’t imagine that we could have the same kind of debate in relation to signatures: who would dare to question our right to sign documents? The right to sign is an integral part of our right to express our identity.
Open Badges are the elements of our identity defined by others (those who have created the badges), Open Signatures are the elements of our identity defined by ourselves: what we sign are testimonies to who we are or who we aspire to be, just as self-issued badges could be. And one of the main advantages of signatures over self-issued badges is that we do not have to bother with “pretty pictures.”
The parapher is at the antipodes of the backpack: it provides everybody with the power to act, rather than the power to pack!
If you are interested by the ideas developed in the post, join us at ePIC 2016 to Hack Open Badges!