Skip to main content

Build

BUILD

As a developer of Open Badges, you have an opportunity to create a system that not only meets local needs but is interoperable with the global digital credentials ecosystem.

How is an Open Badge Constructed?

It is important to understand a few key terms and concepts before designing a system that supports Open Badges.

Open Badge — Open Badges are verifiable, portable digital badges with embedded metadata about skills and achievements. They comply with the Open Badges standard and are shareable across the web. Each Open Badge is associated with an image and information about the badge, its recipient, the issuer, and any supporting evidence.

Issuing Open Badges requires constructing and publishing a set of interconnected resources that follow the structure and guidelines set out in the Open Badges standard. A single Open Badge (sometimes called a “badge instance”) consists of a unique set of one each of an Issuer, BadgeClass, and an Assertion, though the Issuer and BadgeClass are often shared across many Badge Instances. When each resource has been created, the Assertion may be “baked” into the badge image, and the badge may be delivered to the recipient. A "baked badge" is a unique characteristic of an Open Badge that ensures the recipient can move the badge from one platform (issuing system) to another (e.g., passport or backpack tool). 

  • Issuer Profile — describes the individual or organization awarding badges. The information in the profile will appear in the metadata for all badges, including name, description, contact email address, and website URI.
  • BadgeClass — the formal description of a single achievement the Issuer recognizes. This includes information such as the name, description, and of course the graphic image that’s the visual face of the badge, but also links to detailed criteria for how the badge may be earned and the Issuer profile that created it. A human-readable criteria page and an image file visually symbolizing the accomplishment must be published at a stable URL. Many Assertions may be issued from a single BadgeClass. 
  • Assertion — the record of an individual’s achievement of the badge. The Assertion links to one BadgeClass and contains the information specific to one recipient’s achievement of the badge’s criteria, like the date it was awarded, the encoded recipient identifier it was awarded to, and optionally a link to evidence and expiration date. 

Ecosystem Roles

Issuer — An application that enables the creation of BadgeClasses and the subsequent issuing of Assertions to earners that conform to the Open Badges specification.

Displayer — An application that displays Open Badges with their associated metadata and also offers verification functionality.

Host — An application that can import, aggregate, and publicly host Open Badges for earners while also supporting the export of badges at the recipient's request.

 

See the Glossary for more key terms.

Open Badges Best Practices Workflow

This image is licensed under a Creative Commons Attribution 4.0 International License.


Decision: Build vs. Buy

A key decision for any organization that desires to create, issue, and manage Open Badges is whether to build the functionality into an existing platform or license access to an external platform for this functionality. 

Build

Systems are built to enable users to create, issue, and manage Open Badges supporting any or all of the following capabilities:

  • Create and issue Open Badges
  • Display and verify Open Badges
  • Import, curate, and share Open Badges

The Open Badges standard (below) is a technical specification that guides the development of these capabilities. IMS provides conformance certification to Open Badge products to ensure interoperability with the broader Open Badges ecosystem of tools and systems. 

Buy

Numerous products and platforms already exist for creating, issuing, managing, curating, and sharing Open Badges.

Organizations that want to issue Open Badges can start by evaluating IMS certified Open Badges products.

Many of these products also offer the ability to integrate with their platform through open or proprietary APIs. 


OPEN BADGES STANDARD

The Open Badges standard is a technical specification for describing how to create, issue, endorse, verify, and exchange interoperable Open Badges. The standard is publicly available and free for anyone to use. IMS Global Learning Consortium manages the Open Badges standard; the Mozilla Foundation originally released it.

Open Badges 2.0 is the current version of the standard that supports all the features described in this site. Open Badges 2.1 (Badge Connect™) provides an optional REST-based API that enables a user-centric exchange of badges between systems. 

A number of free resources exist for implementers of the Open Badges standard:

Membership in IMS is not required for use of the Open Badges standard. However, IMS members receive additional benefits including product certification and access to reference implementations, source code, and technical project groups. 


KEY FEATURES

Open Badges support a variety of powerful features that distinguish them from other types of digital badges:

Alignment — Open Badges may include URLs that point to the official description of the target of the alignment. For example, a badge may be aligned to a competency or academic standard published in an external framework. 

Criteria — Open Badges can contain detailed information about the requirements needed to earn the badge. 

Endorsements — Open Badges can contain endorsements (claims of support made by third-parties) regarding BadgeClasses, Assertions, or Issuers. For example, a professional association might endorse an educational institution's badge offering (BadgeClass), or an internship supervisor might endorse an Assertion issued to an intern related to workplace professionalism.

Multi-lingual — Open Badges can use tags to declare the language in which the badge object is written. Additionally, issuers that want to offer the same badge in different languages can list those equivalent versions. Finally, developers who wish to write code in a language other than English can build a JSON-LD context file in their preferred language and then encounter badge property names familiar to them and their teams.

Revocation — Open Badges may be revoked by issuers, if necessary. The revocation method required differs depending on whether the assertion is a hosted or signed assertion. 

Verified iconVerification — Metadata about the badge, recipient, and issuer are verifiable using one of two available verification methods. Verification of hosted assertions entails calling the stable URI of the assertion and BadgeClass, checking that they exist, and ensuring the domain origins match or are explicitly allowed. For assertions that are digitally signed (JWS), verification uses the public key to carry out a verification check.