I had the opportunity to hang out with David Leaser and Jim Daniels on their Digital Badge Academy webcast to discuss how endorsement works with Open Badges and Verifiable Credentials within trust networks.
If you’re interested in this kind of thing, I’ve written a few blog posts, and have another one ready to publish on the WAO blog:
Open Badges are web-native digital credentials that allow anyone to recognise anyone else for anything. One popular approach is microcredentialing, although there is a growing movement around Open Recognition.
It’s not long since the third major version of the standard was released, with this one aligning with the W3C’s Verifiable Credential data model. If that sounds like a mouthful, and if reading specification documents makes your eyes glaze over, here’s a few highlights to explain what’s new.
1. A Farewell to Email Addresses
Although it’s technically been possible to use something other than email addresses in previous versions of the Open Badges standard, almost nobody has done so. Using an email address as an identifier can be problematic in terms of privacy, security, and long-term maintenance, as email addresses can change or become inactive over time.
Verifiable Credentials use a decentralised identifier (DID), which provides a unique, persistent, and secure way of proving who you are. This can be based on virtual wallets built into web browsers and smartphone apps, although they don’t have to be. In fact, you can generate a DID from a phone number or email address.
The DID method ensures greater privacy and security, as well as long-lasting recognition of achievements, independent of changes in the recipient’s email address. Although there may be a little bit of confusion to begin with, hopefully badge platforms will make this extremely easy to use.
2. Image-free recognition
One of the mandatory requirements of Open Badges is to use some sort of image. In fact, the metadata is hard-coded into the image as part of the ‘baking’ process. I do like a good badge image, but sometimes they can be a barrier to recognition because organisations want to ensure consistency with a house style.
With Open Badges v3.0, the alignment with the Verifiable Credentials data model means that there is no longer any requirement for an image. Verifiable Credentials are primarily focused on data and use something called JSON-LD (a standard for linked data) to describe the content. This approach means that the badge/credential is both human- and machine-readable.
While I hope it’s not the end for images in badges, I do think that it’s incredibly helpful to be able to recognise others quickly and easily.
3. Greater control
With Open Badges, the badge earner has to either share none of the details (the metadata) about their badge, or all of it. Verifiable Credentials allow for more granular control using ‘Verifiable Presentations’. This means that holders can choose what information to share and with whom, giving them greater autonomy and flexibility.
There are all kinds of things possible with this approach, including for example having an ID card in the form of a Verifiable Credential. Using the Verifiable Presentation approach, an individual could, for example, remain anonymous while still being able to prove that they are of a legal age to buy alcohol, or have the correct licence to drive a car.
In a learning context, someone could choose to create a Verifiable Presentation of several of their badges/credentials for the purposes of applying to university or for a job. Alternatively, the Verifiable Presentation could be made up of different people’s data showing the skills and achievements of a cohort. It’s very flexible.
As the technological landscape of learning and development continues to evolve, it’s important for educators and organisations to understand what’s possible. While Open Badges v2.1 is a great standard upon which to build, the opportunities with v3.0 using the Verifiable Credentials data model are exciting! I’m looking forward to starting to issue badges using the new approach, and sharing more information as I go.
I did not think then, nor do I think now, that IMS are a fit and proper steward for the Open Badges standard. Developing standards behind closed doors is antithetical that everything that Mozilla stood for when I was on the original Open Badges team. It leads to power grabs by small groups with interests unaligned to the wider community, and that’s exactly what’s happening now.
Over the past few years, Kerri Lemoie, Nate Otto, and others have attempted to steer a true course for the Open Badges standard towards the wider W3C Verifiable Credentials standard. (The W3C is the organisation responsible for developing standards for the web.) They have done this openly and transparently.
Behind closed doors, a faction of IMS members, perhaps wishing to hitch their bandwagon to the community-driven success, are trying to claim that the CLR is somehow the apotheosis of Open Badges. As anyone familiar with the last decade of the standard’s development will be aware, this couldn’t be further from the truth. Merging Open Badges with the CLR only serves IMS member interests: they would get to remove Mozilla’s trademark, shut down open repositories, and continue to ignore community involvement in the ongoing success of the standard.
As far as I’m aware, there is a meeting at IMS to move this to a member vote THIS WEEK — which does not give those with an interest and a stake in the ecosystem much time to respond.Update: Colin Smythe says “No deadline has been set. I would expect several more weeks of discussion and reflection. For the time being feedback should be to this GitHub repo.”
So please do consider going here and adding a comment. (If you can’t do that, please consider giving a ‘thumbs-up’ to comments with which you agree!)
To be clear, the proposal to merge with the CLR is an existential threat to the Open Badges standard. While v2.0 of the standard would continue to exist as a pre-IMS standard, there would be no future standalone version of the Open Badges specification.
I could make this post much longer, explaining how Open Badges are a great fit for Verifiable Credentials, railing about the US-centricity of the CLR, and complaining about the practices of IMS. But instead, I will end with an entreaty to add your comments to the GitHub thread.
Let’s focus on Open Badges as Verifiable Credentials and keep the momentum going. Let’s ignore the distraction of those wishing to limit the size, scope, and success of Open Badges to only those areas that they know well. Open Badges is so much bigger than one person, one organisation, or one sector.