Achieve compatibility with OpenBadges 3.0

What is OpenBadges 3.0?

The OpenBadges project was initially conceived around 2011 by Mozilla. Their aim was to develop a new way of recognizing and validating learning, particularly in informal and non-traditional educational contexts. The idea was to create a system that could acknowledge skills and achievements that might not be captured by traditional academic credentials.

The initial release has been developed further and gained much traction over the last years. It is today the most used digital credential format with around one thousand partners involved in the ecosystem. This development was initially independent of the SSI-Community, since it was based on a Client-Server model, where the Badges issued don't really exist on the clients' devices, but are provided by vendors like Moodle or Credly which issued Badges to so called backpacks.

Over the last two years, the OpenBadges Community has been working on a new version of the standard, which is now called OpenBadges 3.0. This version is based on the W3C Verifiable Credentials Data Model and is fully aligned with what is happening in the rest of the SSI ecosystem.

Here is the latest version of the specification: OpenBadges 3.0, which has been in effect for a few weeks.

Many of the OpenBadges participants are organized within the 1EdTech Consortium (formerly the IMS Global), which is driving most of the standardization process, as well as the Digital Credential Consortium (DCC), which is a group out of MIT.

Aligning Identus with the OpenBadge 3.0 specification, so that OpenBadges-compliant credentials can be issued and verified with the Identus agents and SDKs, could be a promising opportunity for gaining more adoption:

Either by developers and SSI vendors who are currently active in the OpenBadge ecosystem, to use Identus for their technology stack.
Or by the Hyperledger community and especially the Cardano/Project Catalyst community to find use cases for Identus outside the Cardano blockchain bubble.
Furthermore, the rest of the developing OpenBadge ecosystem also has wallets (e.g., the Learner Credential Wallet (MIT)) and issuing platforms which could be leveraged by the community.

Technical requirements

The OpenBadges 3.0 specification is based on the W3C Verifiable Credentials Data Model 2.0. This means that the Identus SDKs and agents need to be able to issue, verify, and present OpenBadges 3.0 compliant credentials. While the Identus agent currently does issue W3C-compliant VCs (1.1), there are several smaller points which need to be addressed to be fully compliant.

I have made Feature Requests for each of those points in the cloud-agent repository, with more Feature Requests to be made in some of the SDKs by someone else as we go along. This ticket should serve as a summary and general discussion point on how/if an alignment with the OpenBadges 3.0 specification should be done.

Required changes

Support the VC Data Model 2.0. Currently, Identus is still aligned with the VC Data Model 1.1 spec. This is a breaking change but mostly only affects the naming of two properties (validFrom and validUntil instead of issuanceDate and expirationDate).
- Feature Request: Support for Verifiable Credentials Data Model 2.0
Additional type property: The Identus agent currently uses type:["VerifiableCredential"] as a fixed value when creating a VC. To align with the OpenBadges 3.0 specification, the type property must be settable to e.g., ["VerifiableCredential", "OpenBadgeCredential"]
- Feature Request: Additional type properties for VC issuance

Optional changes

Extendable JSON-LD Context: The Identus agent currently uses a fixed, unchangeable @context for the VC. OpenBadges should use an additional context for appropriate RDF parsing. Since the JSON-LD Context is not a required property of the VC Data Model 2.0, I would treat that as optional.
- Feature Request: Extendable JSON-LD Context for VC issuance
Extendable Issuer property: Currently, the Identus agent uses a string to describe the issuer, e.g., issuer: "did:prism:123...". OpenBadges 3.0 leverages the full freedom of the VC spec to use an object here instead, which might contain not only the identifier but also the name (e.g., ABC University), a description, as well as an image.
- Feature Request: Extendable Issuer Property for VC issuance
Support for other DID Methods: Currently, the Identus agent only supports the DID-PRISM method. OpenBadges 3.0 is not bound to a specific DID Method, but it recommends either did:key or did:web. While expanding Identus to support more DID methods is on the roadmap anyway, and did:key and did:web are low-hanging fruit, I won't be making a separate Feature Request for this. If we can achieve Universal Resolver support for did:prism (which is also on my roadmap), we might not even need to tackle this point.

hyperledger / identus