Review "Open Badges API" Section

[amiller-ims]

This issue was created to capture a discussion of the OB 3.0 API.

The draft 3.0 API in the base document is an update to the BadgeConnect API™ defined in [OB-21]. It was designed with these goals:

• Keep the [OB-21] style of API in the base document (also adopted by [CLR-10]) with payload modifications as necessary.
• Update the security parts to conform with the IMS Security Framework 1.1.

Reviewer Tasks

• Review Section 6. Open Badges API and provide feedback

[justinpitcher]

Related to #352 IMS Base Document

[amiller-ims]

For those of you looking at the API, the CLR version is a little further ahead: https://www.imsglobal.org/spec/clr/v2p0#api (you need to be logged in to see this document). In particular, section 5.3 REST Endpoints is generated from a new (in progress) ServiceModel in the clr_v2p0.lines file. I renamed the REST endpoint to ims/clr/v2p0/credentials (was .../clrs in CLR 1.0). And I think it could be ims/ob/v3p0/credentials in OB. I initially experimented with using a VP for the response payload, but it got WAY too complicated trying to handle both CompactJws (VC-JWT proof) and JSON (LDS proofs) formats, and ended up using a GetCredentialsResponse class.

The two VC APIs that have traction are W3C VC-API and DIF OIDC API. Both are centered around issuing and verifying credentials. While the CLR 1.0 and OB 2.1 APIs are built around moving credentials that have already been issued, and assume the entity that has the credential will do their own verifying. I think there is a place for the CLR 1.0/OB 2.1 style API and the emerging VC APIs. I don't think we should abandon the CLR 1.0/OB 2.1 style APIs.

[xaviaracil]

@kayaelle @ottonomy Since the spec is already in Candidate Final, is it ok to close this issue?