Pull request #99: Open Badges 2.0 Recommendation

[Nate Otto]

Open briefly for comments, here is the specification update that you have contributed to over the last 20 months of Badge Alliance-led calls and activities. https://github.com/openbadges/openbadges-specification/pull/99

With this update, we move forward into 2017 with a great foundation from which to launch a new round of standardization activities within IMS Global. 

Stay tuned for publication, and feel free to comment or question on the GitHub ticket or in this mailing list thread.

Implementers, I and representatives from IMS Global will be available over the coming month to collaboratively plan implementation of 2.0, especially in order to update and test relevant validators. Contributions welcome.

-------------

This is a preliminary pull request to merge the 2.0 draft (see on staging server here) into master to publish it as the final recommendation of the Badge Alliance to hand over to the IMS Global Open Badges Working Group in 2017.

The Badge Alliance has collected feedback and proposals from over two dozen stakeholder organizations and compiled a number of desired use cases in mid-2016.

These use cases were prioritized by organizations and individuals who wanted to contribute to standardizing solutions to them in the Open Badges Specification and advanced to issues on this repository.

I worked with members of the BA Standard Working Group to draft a recommendation containing minimal breaking changes and a robust set of new features, putting Open Badges on a firm foundation for years of improvements to implementations as well as clearing the way to a better ability to experiment with the vocabulary and providing the tools for future updates to avoid breaking changes for even major improvements. 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.

Optional new features:

• Endorsement (#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)

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 idproperty, 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)

Timeline:

• Minor adaptations to the 2.0 branch to reincorporate v1.1 in the history section for reference.
• Pull request merged and 2.0 recommendation published to openbadgespec.org
• January 2017: IMS Global officially adopts the Open Badges Specification as announced in October and uses this 2.0 Recommendation as the starting point of discussions in their new working group. The Badge Alliance activities pass the baton over to IMS Global and other organizations to carry Open Badges forward
• Verifiers, backpacks and issuers begin to be updated to support the 2.0 Recommendation. Once 2 open source verifiers, 2 open source backpack providers, and at least 2 issuer platforms or applications are updated to support 2.0, we expect adoption to be considered final and 2.0 to be the official version of Open Badges.