Technical Resources

Issuing digital credentials requires a couple of considerations that influence the choice of technology both short and long-term. In theory, creating and delivering a digital credential, e.g. in the form of an Open Badge, is nothing more than adding some meta-information in a defined format to a container, and "giving it to the recipient". The practice is a bit less straightforward.

The right container

Currently (2023), there are two "open" and well-defined containers for digital credentials: OpenBadges and Verifiable Credentials, in addition to proprietary ones (e.g. Microsoft).

OpenBadges

OpenBadges were originally specified 10 years ago, with Version 2 and 2.1 currently active. Version 3 has not yet been formally released, but e.g. Canvas (formerly Badgr) are already using it as default in their suite. Some differences are, among others: badge image being optional; additional meta tags, eg. skills, endorsement; better alignment with Verifiable Credentials. Version 3 is likely to be formally specified in mid-2023 by IMS Global.

Verifiable Credentials (VC)

As a proposed standard from W3C, the VC is a universal container able to represent all sorts of digital credentials, certificates etc. It is compatible with OpenBadges, especially with OpenBadges 3. VC is currently in a test phase, but several credentialing projects are already using it, e.g. dock.io.

Provider vs. Self-hosting

There are basically two options to implement digital credentialing and issuing; either by using a (commercial) credentialing provider or by hosting it yourself.

Credentialing provider

Commercial credentialing providers or platforms were some of the biggest sponsors of the OpenBadges development, and, not surprisingly, they tried to build a business model around it. That resulted in their diversification into several areas, e.g. Badgr being acquired by Canvas, an education LMS ; Credly going deep into workforce analytics, skills development and course aggregation; Open Badge Factory into communities of recognition etc. All platforms make it easy to issue badges through integration into LMS/LXPs (see below), and typically consolidate all data within their platform. This allows issuers to offer services like learning paths, advanced analytics and stackability (assembling several credentials to a bigger one). In addition, it is possible to issue credentials "manually", which can be an attractive option if you don't have an LMS integration, or if you want to play with it.

Most providers have a pricing model around the number of issued badges/credentials, and the services offered. If you issue below 100 badges, you will pay only a small amount, but if you plan to issue 10,000+ per year, the costs can become substantial. And because migrating to another platform at a later stage can be "challenging", we definitively recommend to be clear about what you need, in order to avoid a costly vendor lock-in.

Many or most of the current providers still use the OpenBadge container, either in Version 2.1 or 3.0 (e.g. Badgr Pro/Canvas), but the first platforms with the W3C Verifiable Credentials format are on the horizon (e.g. dock.io).

UPDATE FROM Sept 6, 2023: WeAreOpen has selected 5 platforms and wrote their recommendations, here: https://blog.weareopen.coop/5-platforms-for-issuing-open-badges-44364e44821

Self-hosting

OpenBadges were initially designed as an open standard (although many commercial companies provided their licenses and patents), but there is currently no supported open-source platform available anymore. Badgr/ConcentricSky released a front- and back-end server (Angular, Python/Django) under an Open Source License, but withdrew the Github repository and documentation when it was acquired by Instructure in 2022. Fortunately, the repositories were saved and can be downloaded here: https://github.com/reedu-reengineering-education/badgr-server and https://github.com/reedu-reengineering-education/badgr-ui.

ICoBC provides a Badgr2.0 Server as playground. If you want to try it out for your project, here.

There are also technical service providers that might contribute to your systems, especially with Verifiable Credentials on the horizon.

Wallets (Backpacks)

In many cases, issuing a digital credential is invoked when a learner / earner has passed some qualification (e.g. course completion, assessment, test, proof-of-work etc.), especially in the context of education / e-learning. This calls for some form of automation (if ... then ...) and the obvious place for this is the Learning Management System (LMS) or Learning Experience Platform (LXP). Most LMSs allow the issuing of digital credentials, either as an integral part, or through an API plug-in, where the issuing and access is managed by an external platform on behalf of the LMS, or both: Moodle e.g. allows connections to external backpacks to issue credentials there.

Digital credentials need to be accessible for the earners / learners. For several reasons, in the past they were mostly stored on platforms that issued them. This "wallet-on-a-platform" was called "backpack" in the OpenBadges specifications, and some still use that name. When a user earns a badge, it is stored there, as long as they have access to the platform, for example in Credly, Open Badge Factory or Canvas (formerly Badgr). Potentially they can download a digital badge, and upload it to another platform. However, and unfortunately, this is not as easy as it may sound and downloading the credential or badge is of limited benefit for the earner, as the meta information in the credential is not easily accessible for a normal user.

With the rise of the digital wallet concept, and to some extent with the idea of a self-sovereign user, the place to collect, manage and give access to earned credentials likely moves away from the platforms. These wallets are typically an important component in larger frameworks, like the "Bildungsplattform" in Germany, or the Prometeus framework in France. They are designed to be largely container agnostic and should be able to deal with all kinds of badges or credentials, likely to include OpenBadges and Verifiable Credentials. They typically go together with a strong user ID, instead of e.g. an email authentication, as is the case with many LMS or badging platforms.

Why is this important? If the sole place to guarantee access to issued digital credentials is your platform, or that of a hosting partner, you are responsible for storing the badges for a long time (tbd). If your system fails and you cannot recreate it from backups, earners cannot access their credentials / backpack / wallet anymore, and you may face legal charges. The wallet is a way to move this responsibility - but also the ownership - to the user.

As we write this, the ecosystems and technological solutions around digital wallets and identities are evolving in a very fast way (partially fuelled by Covid-19): big players (Apple, Google/Alphabet, Microsoft) try to set the scene, and nations attempt to establish national IDs with surrounding services (including credentials). At the same time, technical and commercial ecosystems, like NFTs, W3C (standardisation) or cloud services (e.g. Gaia-X, AWS, Azure) become available and compete with each other.

If you have the technical capabilities and wish to self host, you could e.g. look into walt.id, which provides SSI (self-sovereign identity) and wallet solutions.

Integration into LMS / LXP

In many cases, issuing a digital credential is invoked when a learner / earner has passed some qualification (e.g. course completion, assessment, test, proof-of-work etc.), especially in the context of education / e-learning. This calls for some form of automation (if ... then ...) and the obvious place for this is the Learning Management System (LMS) or Learning Experience Platform (LXP). Most LMSs allow the issuing of digital credentials, either as an integral part, or through an API plug-in, where the issuing and access is managed by an external platform on behalf of the LMS, or both: Moodle e.g. allows connections to external backpacks to issue credentials there.

In case you want to issue only few digital credentials, you could do this manually via an external provider, as listed above.

Data Security and Ownership

Issuing digital credentials involves dealing with sensitive data, access to and control over it. Many countries have legislation governing this (like the European Union with the GDPR). But apart from that, you need to make sure that the credentials data is safe and protected. This is even more important for vulnerable groups, such as people distant to the labour market. Their trust in and understanding of technology might be limited, and fear of exposing their data in an uncontrolled way could significantly ruin your intentions with issuing digital credentials in the first place. As such, data security comprises at least the following two aspects:

  • Ensuring access to credentials, even after leaving the organisation / program, ideally life-long; and making sure that the technology used is available and supported for a long time.
  • Educating earners about due behavior and potential risk (like storing, sharing).

The second topic, ownership of data, is also to consider. At the end of the day, learners and earners create a trove of potentially valuable data, be it on course performance, program success, individual profiles, marketing efficiency, or stackability of courses, to name just a few. If this data is something you want to work with, you likely do want to have full access and not leave it to third parties. Likewise, this data is one of the biggest reasons why credentialing platforms want to make an all-inclusive package: having all kind of credentialing data in one place is a powerful business model.

why
what
how
pilot
scale