Providing some clarity on Open Badges 2.0
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.
Background
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.
What’s changed?
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).
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.
Badge Class
- 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.
Assertions
- 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.
Misc.
- 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.
Further reading
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.
- Developer’s Guide to Issuing Open Badges 2.0
- Awarding Open Badges with 2.0: Recipient Identifiers
- Open Badges 2.0 Profiles and Recipient Identifiers Deep Dive
Questions?
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!
Final note
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
