remove vc-http-api

[bluesteens]

It is my understanding that vc-http-api has been developed with a focus on interoperability testing, but is not perfectly suitable for OCI's use cases, i.e. essentially day-to-day W2W exchange of VC.

See also: https://github.com/w3c-ccg/vc-api

These APIs provide a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).

Thus, I suggest to remove this requirement from the wallet criteria.

• https://open-credentialing-initiative.github.io/Digital-Wallet-Conformance-Criteria/latest/#credential-issuance-exchange

[bluesteens]

raised at P&A call on Oct 20. pending review.

[alexcolganLD]

Agreement from XATP, let's remove.

[alexcolganLD]

The P&A Committee proposes that the Steering Committee remove the HTTP-VC-API optional requirement from the Digital Wallet Conformance Criteria. The reasoning for this is provided below.

Background:

• The Digital Wallet Conformance Criteria outlines two methods for issuing and exchange credentials: DIDcomm and vc-http-api.
• DIDcomm is required for all Wallet Providers, handles both credential creation and transport, and is a mature and ratified specification of the Decentralized Identity Foundation.
• VC HTTP API is optional, only handles credential creation, and is a draft project of the W3C Credentials Community Group.

Rationale for removal:

• The primary goal of OCI is interoperability -- between VCs, between wallets, between Credential Issuers and Wallet Providers, etc. With DIDcomm, any Credential Issuer using any OCI-compliant wallet can issue credentials to any OCI-compliant wallet. VC HTTP API would require a separate, as-yet-unspecified method to transport the credentials to other parties (as called out in the conformance criteria). As such, it lacks many of the out-of-the-box capabilities of DIDcomm, and its use would negatively impact the confidence of counterparties relying on the credentials.
• The removal of the VC HTTP API option is not expected to negatively impact any potential Credential Issuer who may wish to enter the OCI ecosystem. The work of DIDcomm implementation falls on the Wallet Providers, who are already required to adopt the DIDcomm standard. Wallet Providers and integrators remain free to implement controls over wallet operations and to optimize workflows and UI (e.g. portals and APIs) for the purposes of issuance, revocation, etc.
• OCI has identified DIDcomm as an area of further exploration and interoperable standards development.

[bluesteens]

removal approved by P&A and Steering committees

[bluesteens]

#26