Earlier this year, I wrote about the importance of thinking about a project’s architecture of participation when encouraging contribution from a new or existing community of people.
In that post, I included a checklist containing eight points to consider. I think I’ve got another one to add: get your policies right by soliciting feedback on them.
We Are Open Co-op is currently in the first phase of creating Badge Wiki, a knowledge base for the Open Badges community. It’s a project made possible through the support of Participate.com.
- CC BY – we propose that Badge Wiki use a Creative Commons Attribution 4.0 International license instead of the CC BY-SA license used on other wikis, including Wikipedia. Although we would encourage them to do so, we recognise that some people may not be in a position to share material they reuse and remix from Badge Wiki under an open license.
- Register to edit – we propose that, in order to edit Badge Wiki, you must have a registered user account, approved by an administrator. This is to prevent valuable contribution time being taken up by wiki vandalism, trolling, and other anti-social behaviours caused by anonymous editing.
- Real name policy – we propose that members of Badge Wiki use their real names on their profile pages, as well as provide a short bio. This is to prevent accusations of sabotage, given that the Open Badges ecosystem includes commercial interests.
You’re welcome to leave feedback on the posts themselves, in relevant Open Badges Google Group thread, or directly to us: firstname.lastname@example.org.
Thanks in advance for your participation and contribution. Remember, comments expressing support and broad agreement are as valuable as expert nitpicking!
It’s been five years since the public beta of the Open Badges specification was released. Since then version 1.0 was released (2013) followed by some smaller updates. The next major release happens in the next few weeks with version 2.0.
As a result, I thought it was worth taking the time to explain what this means both on a technical level and, more importantly, in practice for those issuing, earning, and displaying badges.
Although Open Badges has grown into somewhat of a movement, at its core is a technical specification. It’s a ‘standard’ in the sense that those who provide platforms and solutions based do so in an interoperable way. Just as there are web standards meaning that you can use any browser to access your favourite website, so the Open Badges specification ensures everything ‘just works’.
The Open Badges specification is now stewarded by IMS Global Learning Consortium, having taken over the role from the Badge Alliance at the beginning of 2017. You can read more about the history and evolution of Open Badges.
Digitalme are looking after the evolution of the Open Badges backpack, the place where uses store and share their credentials. I’ve written about this recently here.
Development of version 2.0 of the Open Badges specification was informed by a ‘use cases’ document developed by the community. The technical work and discussion around it took place via regular, open meetings, and via this GitHub repository.
Most, but not all, of the proposed changes outlined by Kerri Lemoie in her post last September, were included in this update.
The new, canonical page for Open Badges 2.0 is on the IMS Global Learning Consortium website. It’s pretty technical, and even the ‘non-technical’ guide involves some discussion of terms many people won’t be familiar with.
Readers of this post are more likely to be interested in what’s new in the specification. What can we do differently to before? Before we look at that, let’s just look at what was previously possible, reminding ourselves of the difference between a ‘badge class’ (i.e. metadata contained in every badge of that type) and an ‘assertion’ (i.e. metadata contained in a badge that’s unique to the individual).
Image CC BY-ND Bryan Mathers
Version 2.0 of the Open Badges specification makes new features available both in the badge class and assertion, as well as other, ‘miscellaneous’ features. Here’s a list of what’s changed. Let’s break those down.
- Endorsements — a type of badge that is issued to a whole range of people can now be endorsed by a third party.
- Use cases include badges that are issued by teachers that are then endorsed by a school, and badges issued by local awarding bodies that are then endorsed by national/international awarding bodies.
- Embed criteria — criteria about what an individual had to do to earn a badge can now be embedded directly into the badge class, using Markdown. Previously, issuers had to provide a hyperlink to a URL on their website giving details of badge criteria.
- Use cases include making badge criteria more machine-readable for issuers, helping their badges become more discoverable. For badge earners, it shows at-a-glance what they had to do to be issued the badge, instead of badge ‘consumers’ having to click through to an external site.
- Endorsements — a badge that is issued to an individual, or subset of the whole group of people who have earned that type of badge, can now be endorsed by a third party.
- Use cases include colleagues endorsing you for a particular workplace skill (kind of LinkedIn endorsements, but on steroids), and getting a well known person or organisation to endorse a badge you’ve already earned. This allows for badges to grow in value over time.
- Embed evidence — the evidence proving an individual has met the criteria to be issued a badge can now be embedded in assertions, using Markdown.
- Use cases include representing the types of evidence that are acceptable to meet the criteria for a badge to be issued, and displaying several pieces of evidence towards a single badge.
- Fully portable — badge classes and issuer metadata can be embedded into assertions, meaning Open Badges don’t have to rely on links that may disappear.
- Use cases include issuers cryptographically signing the entirety of the metadata associated with a badge, to enhance verifiability, and badge earners not being faced with ‘incomplete’ badges if a badge platform no longer exists.
- Internationalisation — badges can now be issued in multiple language, and users can see that this is the case.
- Version control — the specification now allows updates to be made to badges and, like a wiki, the differences between versions can be viewed.
- Embed information about badge images — just as regular images on the web have ‘alt’ tags to allow them to be more accessible to people with disabilities, so Open Badges can now include information about the image representing them. This also helps make badges more machine-readable.
- Award badges to non-email identities — some of the biggest complaints about Open Badges stem from email-based issuing. Now, badges can be issued to identities other than email, including social logins and verified profiles.
- Improved alignment — while it’s already possible to enter a URL that shows a single framework or standard that a badge aligns with, version 2.0 allows a badge to reference multiple frameworks/standards.
Is everyone using 2.0 now?
No. It’s up to individual providers to update their systems. All of the sponsors of Badge News are 2.0-compatible, and the rest of the ecosystem should adopt the new standard in the next few weeks and months.
Verifiers, backpacks and issuers begin to be updated to support the 2.0 Recommendation. Once 2 open source verifiers, 2 open source backpack providers, and at least 2 issuer platforms or applications are updated to support 2.0, we expect adoption to be considered final and 2.0 to be the official version of Open Badges. (source)
If you’re already issuing badges, you might wonder about compatibility between different versions of the Open Badges specification. The short answer for 99% of use cases is that yes, the specification is backwards-compatible. The longer answer is explored on the IMS Global changes page.
If you want to go into a bit more detail, Nate Otto, Director of Open Badges for Concentric Sky (and former Director of the Badge Alliance) has written some helpful posts.
I’ve spent the last six years working in and around Open Badges, first as a volunteer, then for Mozilla, and now as a consultant. If I don’t have the answer to your question, I’ll probably know someone who will!
I’m co-founder of We Are Open Co-op and we’re currently working Badge Wiki, which will be a knowledge repository for the Open Badges community, made possible by Participate. It will eventually contain the kind of information that this blog post covers, so make sure you sign up for updates to find out more.
Image CC0 Aaron Burden
I’m delighted to announced that my article for Stir to Action magazine, ‘Digital Employability for the New Economy’ will be published in their Summer 2017 issue entitled The Cult of Innovation.
Those paying close attention to this blog will have already seen the draft of this article and I encourage everyone to buy the magazine, or better yet, become a subscriber (like me!)
- Law Column — Ana Stanic
- Commons Column — Michel Bauwens
- The Cult of Innovation — Dan Gregory
- Rural Project — Ben Eagle
- Rethinking Education for Co-operation — Cilla Ross
- Digital Employability for the New Economy — Doug Belshaw
- Interview: Brianna Wettlaufer & Nuno Silva
- The William Morris Economy — Simon Parker
- Post-Brexit: English Futures — Andy Goldring
- Q&A: Imandeep Kaur
- The Ethics of Economics — Matthew Wilson
- Playing for our Lives — Inez Aponte
- Review: Kate Raworth’s Doughnut Economics — Anna Laycock
Update: I’ve slept on this, and think that the ‘Credential Switch Guarantee’ isn’t quite the correct metaphor, as there’s nothing ‘in the middle’. A better model might be that of escrow, but even that isn’t perfect. I’ll keep thinking…
Last week, Jason McGonigle, CTO of Digitalme got in touch to say he’d written a blog post about the future of the Open Badges ‘backpack’. For those unaware, here’s a quick history lesson.
In the early days of Open Badges it was felt that Mozilla needed a place that any earner, no matter where they had earned their badges, could store and display them. This was seen as somewhat of a ‘stopgap’ measure. The priority after launching v1.0 of the specification in 2012 was to ‘decentralise’ the Open Badges ecosystem by federating the backpack.
This federation, in practice, was more easily said than done. Three things caused it to be problematic. First the inevitable politics. There’s no need to go into details here, but the spinning out of the Badge Alliance from Mozilla was doomed to failure. As a result, the focus on federating the backpack (and on creating BadgeKit to make badge issuing easier) went by the wayside.
Second, there were technical issues beyond my understanding with federating the backpack. Apparently it’s a very hard thing to do. Third, the need for federation is just something that’s quite difficult to explain to people. We’re so used to centralised services. I used to try and do so by talking about the way email works. These days, my example might be Mastodon.
As a result, Mozilla’s backpack became a central piece of the Open Badges puzzle. That, I think, actually worked to the advantage of badge advocates. While the Open Badges specification can be rather technical and dry, there’s something about the backpack that’s ‘homely’ and easier to explain to people. Having somewhere to store and show off your digital credentials just makes sense.
Carla Casilli, my former colleague at Mozilla, wrote a post this time last year in which she gave her views on the backpack and explained how it is rooted in ideology:
So much ink has been spilled already on the subject of the Mozilla badge backpack: almost from the start it has been both an important philosophical stake in the ground about personal data ownership as well as a raging battleground about its necessity. Questions about it have abounded. What works, what doesn’t. Who uses it, who doesn’t. What’s happening with it, what has happened to it. And yet, even with all of this back and forth, there has always been so much more to say about it.
Jason alludes to user sovereignty in his post, but I think Carla really nails it in hers:
One of the best unheralded benefits? When a badge earner used the reference implementation of the Mozilla Open Badges backpack, there was no requirement for them to be a member of a separate, corporate-owned social network in order to display their badges. Not at all.
In other words, users need a place to store and display their badges that aren’t tied to badge issuers. End of story.
These days, there’s no-one at Mozilla working on Open Badges. That’s been the case for at least a couple of years now. Instead, Digitalme were given a contract by Mozilla to continue work on the Open Badges backpack, while overall development of the standard is now the responsibility of IMS Global Learning Consortium. This, and the fact that there’s no badge track at MozFest 2017 tells you all you need to know about Mozilla’s future plans around badges.
So we’re left in the situation where one of the major players in the Open Badges landscape is responsible for a key bit of infrastructure. It’s not ideal, even if I know and trust the people at Digitalme.
The backpack is, and always has been, a place focused on user choice and control. I certainly hope it stays that way, and think that Jason’s vision of a ‘Credential Switch Guarantee’ might be a workable one. Users need something tangible that’s independent of commercial offerings.
Long live the backpack!
Image CC0 Alexandre Godreau
Interested in Open Badges? Subscribe to Badge News!