Endorsement: an #OpenBadges paradigm shift, thanks to @ottonomy

Thanks to Nate Otto (@ottonomy) an extension for endorsement of Open Badges is currently under review (link). I would like to explain why this ‘extension’ is much more than a simple add-on to an existing specification but a breakthrough, an invitation to a paradigm shift (yes, nothing less Nate!)

The proposed extension is the outcome of the discussions (link) in the Badge Alliance Endorsement Working Group (link) lead by Deb Everhart (@ariadne4444). A collaborative document was produced to capture our work (link).

Here is how endorsement was defined in the original working group brief:


The Endorsement Working Group is developing the conceptual and practical framework for the endorsement of open badges. Endorsement is a game changer for how badges are used, understood, and trusted, because it allows third-party organizations [highlited by me] to publicly indicate which badges are aligned with their values—those that are the most meaningful and useful to them […].

What was implicit in that brief and in the initial discussions was that the kind of endorsement we were invited to explore was in relation to providing the means to organisations to attach their name to a badge, so those badges would be more visible, more desirable and trustworthy — for the potential earners and consumers.

While giving the power to organisations to endorse badges is a perfectly legitimate goal, there were a number of risks associated:

  1. Asymmetry: the current Open Badge Infrastructure is deeply asymmetrical: it is issuer centered and not earner/learner centered. As issuers are mostly organisations, giving additional powers to organisations without giving equivalent powers to badge earners would be likely to widen the chasm.
  2. Impoverishment: the underlying assumption was that the kind of badges that would be endorsed would be in relation to competencies or at least to some kind of standards. While it is clear that badges will be used to do better what we already do, like recognising competencies, there are probably thousands of things we could do with digital badges that were never done before their invention. By putting too much emphasis on the need for “alignment with standards” we are taking the risk of conformity and that of smothering innovation.

Here is the next part of the endorsement working group brief:

[…] It adds a new metadata component[highlited by me], to the open badges standard and defines the structure for rich, well-defined endorsement information and criteria such as alignment with standards [highlited by me], uses for the badge in the context of the endorsing organization, description of evidence of learning and assessment techniques the organization values, etc

In response to the idea that, in order to represent endorsement, we would need to add a new set of metadata, my first reaction was to say: why don’t we simply use badges? In the past, we had discussions about “badge the badger”, i.e. use the badge as a kind of endorsement or authorisation for the issuer to issue certain badges. One of the problems with the idea of “badge the badger” is the fact that badge issuers do not need a backpack, so where would they put their “badges as badger” (issuer). The response seemed obvious: let’s make a requirement for the badge issuers to have a backpack (or an Open Passport, soon!). The backpack /passport would the place where the different links of the chains of trust would be connected.

While requiring issuers like earners having a backpack/passport would make sense if we believe that everyone should be an issuer/earner/consumer (just like in eBay where we are simultaneously buyers and sellers) how about the endorsement of Open Badges? Notwithstanding that there are different levels of endorsement:

  • Badge class: an abstract representation of a badge that can be shared by different organisations, describing the criteria, assessment modalities, etc. — is this badge fit for me/purpose? I would like to endorse that badge, independently from who actually delivers it (because I believed that the badge designer controls the issuers)
  • Badge issuer: the person (or automaton…) actually delivering the badge — can I trust a badge issued by this issuer? I would like to endorse this issuer as I have good experience with the people who got badges from them!
  • Badge earner: the assertion baked in a picture — I would like to endorse that person for those skills, so I would like to endorse the assertion she already has.

So, while the idea of providing everybody with a backpack would work for endorsing earners and issuers, how could it work for a badge class (which is also a badge)?

This is where the solution for endorsement designed by Nate is brilliant: instead of imagining a solution centered on a particular role (designer, issuer, earner, consumer) the solution is badge centered: the endorsement of a badge is… a badge, but to the difference of the solution I initially imagined, that the endorsement badge would go into the backpack/passport of the endorsee, the endorsement badge is directly connected to the badge itself:

Endorsement badge:

  • issuer: the endorser
  • earner: the badge (class or assertion)
  • criteria: whatever they are
  • evidence: whatever the endorser wishes to disclose

This way, badges do not need a backpack/passport to exist as chains of trust (backpacks/passports will be still extremely useful but for different purposes, but that will be for a following post!).

As you can see in the picture below, currently badge assertions make reference to an issuer, an earner and are stored in the earner space. With the new specification, in order to earn a badge, the candidate simply needs to create his/her own badge, and it will be this self-issued badge (the small blue ones) that will be ‘endorsed’ by the badge issuer. Of course, this badge can be stored in a backpack, but it could be anywhere else, as it carries with it the information related to the trust relationship.

So what Nate has achieved, is not only to offer a general solution for endorsement of badge classes, or badges instances (assertions), but a general solution for badge issuing altogether and the creation of networks of trust. This is the opening for a total paradigm shift while keeping the compatibility with the existing infrastructure.

And this is very much in line with the SDSI/SPKI model suggested a few years ago and brought to our attention by Michael Evans a few weeks ago (link)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.