Open Thinkering

Menu

Verifiable Credentials and Open Badges 3.0: What’s changed?

Note: cross-posted at LinkedIn

Close-up of skateboard wheel with text 'Getting up to speed with Open Badges'

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.

Conclusion

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.


Image CC BY-ND Visual Thinkery for WAO

Leave a Reply

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

css.php