Open Badges as Verifiable Credentials
In the W3C VC-EDU call on June 7, 2021 we discussed Open Badges asserted as W3C Verifiable Credentials (VCs). This call began the public discussion of Open Badges as Native VCs (potentially as Open Badges 3.0) to inform the IMS Open Badges Working Group. Why are we discussing this? Why does it matter? How will it work? Feedback from folks in the community have suggested that it would be helpful to answer these questions first from a conceptual standpoint. In a later post, we can outline what the structural changes could look like.
Open Badges are digital credentials that can recognize learning, achievements, and even memberships. They look like an image, but inside the image are metadata properties (it works much like how digital photos have metadata properties that explain the data of the photo, location, etc. so that when the photo is uploaded, applications understand the data). The metadata describes why the badge was issued, when, the recipient (typically an email address), the description and criteria of the achievement, and, critically, how this digital credential can be verified.
The verification of an Open Badge is dependent on the Issuer of the badge. It can be done in one of two ways:
- Hosted Verification — One of the metadata properties of an Open Badges is the assertion id which is a URL that hosts the metadata in a .json file. If that URL can’t be found, then the badge is not verifiable
- Signed Verification — An Issuer can digitally sign the metadata of a badge. This uses cryptography to ensure that the badge data has not changed and that the issuer was the entity that issued the badge. The public key used to sign the badge must be traceable back to the issuer.
Primarily, Open Badges platforms are issuing hosted badges. This means the verifying party is dependent on the issuer to host the data. Also, the issuer has some ability to track when the badge data has been accessed and potentially by who (or at least by IP address).
For 99% of the badges that have been issued to date, this is fine. In fact, badges are often shared via web pages that attractively display the image and data (not by the .json files that contain the data or the baked image with the data inside). So while Open Badges are both human readable and machine readable, the human readable approach is what is used most often. Signed badges are closer to Verifiable Credentials because they also rely on cryptographic proof.
Neither of these approaches give learners control of their data and this is the overall conceptual shift between Open Badges 2.0 and Open Badges as Verifiable Credentials.
Verifiable Credentials, like signed Open Badges, are signed by the issuer and verified cryptographically. Decentralized Identifiers (DIDs) can be used to identify the issuer and recipient (using DIDs in Open Badges 2.0 has been prototyped). Also, Verifiable Credentials have a concept called “Presentations” which can be digitally signed by the recipient to prove that they are the recipient of the verifiable credential(s) being presented. All in all, this means that the issuer is verified and also the recipient.
Verifiable Credentials can be displayed, shared, and presented from wallet applications that are web, mobile, or desktop based (most are mobile right now). Recipients can present one or more of their credentials to verifying third-parties who can verify the credentials without depending on the issuers and consume the data. Not only can the participant manage which credentials are being verified, they can control what aspects of their data are being shared.
For example, a student’s digital wallet may contain a digital passport, an Open Badge representing a completed course, and an Open Badge representing a student ID (all as Verifiable Credentials). A relying third-party, such as a potential employer seeking to fill an internship role, may need to verify that a student is over 18, has completed a course on communication, and is a current student. The employer’s website application can ask the student to provide this discrete information using their wallet and the student can do this without revealing any of the other information in those credentials like their date of birth, address, photo, or even the name of the school they attend. And all of this information can be verified without contacting the issuers of those credentials. Open Badges 2.0 can’t do this.
Verifiable Credentials put learners in the center of a trust triangle with issuers and verifiers. They also add an additional layer of verification for the recipients. Open Badges can take advantage of this, be the first education-focused digital credential spec to promote personal protection of and access to data, and be part of the growing ecosystem that is exchanging Verifiable Credentials.
It’s worth noting that the human readable aspect of Open Badges would not change in a VC version. Issuers can still display web pages for the issued badges and allow recipients to share their badges online from those pages. The difference being that those web pages would not be reliant on for machine verification or consumption.
Join us for this continuing discussion in the next VC-EDU call this coming Monday June 14 (and most Mondays) at 8am PDT / 11am EDT / 4pm BST / 5pm CEST. This call is public and all are welcome to join. For this Monday’s call (6/17), the zoom info has changed:
https://us02web.zoom.us/j/89426035740?pwd=dmQ0QS9wMUdFaGo0eFcwbkplV3RjUT09
