Tag: specification

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).

What's inside an Open Badge?

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.

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.

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

Help me write my job spec. for next year!


(The response I hope not to get come September…)

I’ve mentioned this in passing in a couple of blog posts previous to this one: from next academic year I shall be E-Learning Tutor at my school. This new post (solicited by me, it has to be said) involves me spending 50% of my time (15 periods of 50 mins) per week teaching History and a bit of ICT. The other 50% will count towards the E-Learning Tutor role.

I’ve a meeting next week with my Head to flesh out my actual role. He mentioned today that I’ll have to do some “mundane” stuff, but that I will be free to push a few aspects of my choosing and accelerate perhaps one thing I’m really interested in. As you can imagine, with my Ed.D. thesis exploring the ‘Digital Literacy’, that’s the latter taken care of. 🙂

I’m expecting the mudane activities I shall have to undertake to be things like:

  • Interactive Whiteboard training (the really basic aspects)
  • How to use the new VLE (Virtual Learning Environment)
  • Using the internal Microsoft Outlook web-based email system
  • Ways to use Powerpoint and other presentation tools in the classroom
  • How to transfer digital video from digital cameras/camcorders to staff laptops

Whereas what I really want to be pushing are things such as:

  • Creating a blog to make resources available outside the classroom (I’ve already run a couple of staff workshops on this, with some success)
  • Basic podcasting and digital storytelling for non-written assessment, leading to e-portfolios for students.
  • Communicating with other educators worldwide (i.e. getting staff initiated in the edublogosphere – perhaps through the K12 Online Conference?)
  • Giving staff the confidence to take students into the ICT suites more often to use the Internet as a publishing tool.
  • Transferring schemes of work and programmes of study into an electronic format (perhaps in a wiki-like format using Google Sites within Google Apps Team Edition or the new VLE?)

Some context to help you understand where we’re at: my school has a plethora of RM One machines, Interactive Whiteboards in almost every classroom, and relatively unrestricted access (we can access Twitter, del.icio.us, Google Video, etc. but not YouTube, Facebook or games websites, for example). There’s a real mix of what I would call ‘digital literacy’ amongst staff. We range from those, like me, who use educational technology in some way in every lesson, to those who only use their laptop to help them write reports, and who certainly haven’t turned on their Interactive Whiteboard yet… 😮

What else should I be looking to include in my responsibilities? How should my success and impact be measured, given that it’s a 1-year trial role? Suggestions in the comments section please! :-p

Image credits: Hugh McLeod @ gapingvoid.com (top one censored by me…)

css.php