Should the OBv3 Data model and Badges API be in the same specification?

[jischr]

I created this issue to start a conversation about the unnecessary coupling of OB3 Data Model and Badges API in the same specification. Specifically, in order to achieve OBv3 conformance, the Badges API needs to be implemented:
https://imsglobal.org/spec/ob/v3p0/draft#conformance-and-certification-guide

There should be a path to OBv3 conformance without the Badges API as forcing the Badges API will decrease OBv3 adoption. An implementer may want to use their existing methods for Verifiable Credential issuance/verification (such as OpenID4VC (#493) or DIDComm (https://identity.foundation/didcomm-messaging/spec/) or the vc api (https://w3c-ccg.github.io/vc-api/) but issue badges as VCs.

How can we change / adjust OBv3 conformance to support these implementations?

[kayaelle]

+1 to this suggestion. One of the primary reasons for the proposal of the OBv3 charter was interoperability with other credentials that will be issued as VCs to applications that understand VCs.

VC wallets could decide to also operate as backpacks and accept Open Badges 2.0 using the 2.1 badgeconnect API but those badges will not have the same functionality as VCs since they won't be aligned with that model. Open Badges 3.0 are VCs and should work like VCs, not have their own proprietary API. Apps operating as backpacks could add VC protocols that @jischr listed above and serve as VC wallets.

VC verifiers will be expecting Open Badges 3.0 to be presented using VC protocols that require cryptographic methodologies that BadgeConnect does not provide. And essentially, the VC protocols & wallet apps replace the concept of federated backpacks since the standards and protocols make it possible for holders to move their data from one to another already.

[xaviaracil]

Initial conformance and certification requirements describes three types of certification:

• Issuer: issues and sends OBv3 credentials.
• Displayer: displays and verifies OBv3 credentials.
• Host: import / export and receive / send OBv3 credentials.

Currently, only Issuer and Host require to conform to some of (or all) the OBv3 API.

One possibilty is to make the API conformance of Issuer optional, so it's not required for certification. Another option is to split Issuer in two, moving the API conformance to a new type of certification. We can also move this API conformance to the Host certification type.

Let's see what the working group have to say.

[xaviaracil]

API conformance is optional in the Issuer certification.