Open Badges Specification Version 2.0 Changes
What has changed in version 2.0?
The following optional new features have been added:
- Endorsements (#73, #76, #79)
- Embed Criteria into a BadgeClass, including a rich (Markdown) text field, narrative. (#74)
- Embed Evidence metadata into an Assertion, and connect multiple pieces of evidence through a narrative in Markdown text. (#84)
- Embed Image information into Badge Objects, enabling greater accessibility of Open Badges. (#82)
- Internationalization and multi-lingual badges are now available (#1)
- Version control and references to previous/other versions of Badge Objects, specifically BadgeClasses. (#53)
- Embed metadata about badge images (#85)
- Award badges to identity types other than email with more explicit instructions (note: backpacks will continue to primarily support email, but we can move the market forward together with this framework) (#77)
- Improved alignment to external frameworks and objectives (#81)
Is 2.0 backwards compatible?
Open Badges 2.0 contains a minimal set of breaking changes. For issuers, it will take minimal effort to move from v1.1 Open Badges to v2.0, as almost every change is optional, leaving the previous option intact. Issuers may then take advantage of the large number of new features as they fit with internal development roadmaps. This is a summary of the breaking changes:
- Linked Data in JSON-LD is now the official data model and syntax of Open Badges. This minimally affects issuers, who were already publishing v1.1 badges in JSON-LD, but all verifiers, backpacks, and displayers of badges must now explicitly perform a JSON-LD expansion/contraction operation to guarantee data integrity before further analysis of any object in the Open Badges context. This is a simplification from the hybrid approach introduced in v1.1 that required issuers to both use valid linked data properties and specific property names.
- The AlignmentObject has been updated to use different terminology. Displayers will be asked to handle the new terms, which is now explicitly based on the schema.org/AlignmentObject class. “description” -> “targetDescription”; “url” -> “targetUrl”
- BadgeClasses may now be embedded into Assertions, Issuers into BadgeClasses, and JSON-LD representations of Criteria, Evidence, and Images may now be embedded into fields that previously expected a URI string value. These new vocabulary classes improve portability, expressiveness, and accessibility of Open Badges. Optional for issuers.
- VerificationObjects have been improved (#87, #80, #78). Hosted verification uses the id property, so verify.url duplication is no longer required or expected (#78). Signed badges are no longer required to discover a key from a url in the Assertion that signs them, closing a security hole. Instead, keys must be linked from the issuer Profile (#89).
- RevocationList documents (used by less than 1% of issuers) are now published under an improved Linked Data class (#33)
- Timestamps should appear in a consistent format (#86)
In-place edits of the 2.0 specification since January 1st 2017
Since the 2.0 specification was published on January 1st 2017, a few errors and typos have been discovered and corrected in-place on openbadgespec.org.
For full transparency, these edits can be reviewed at the GitHub Open Badges master branch commit history page. The first in-place edit was committed on January 10th of 2017.
- April 9th of 2020 the work group decided to require usage of PNG or SVG for all images under this specification.
Please note that the IMS Global version of the Open Badges specification, which contains additional formatting and layout changes, are not reflected in the master repository commit history.