Snapshot VC Issuer/Verifier API for VCWG?

[msporny]

A few organizations have noted that they would like to publish a stabilizing subset of the VC API as a NOTE in the VCWG. The NOTE will specifically provide the VC API calls necessary for generating a Verifiable Credential, generating a Verifiable Presentation, verifying both a Verifiable Credential and Verifiable Presentation, and checking the status of a Verifiable Credential. This issue is meant to track 1) which organizations desire to do this, 2) what we should do with the presentations section of the specification, and 3) when we'd like to propose this to the VCWG.

[mkhraisha]

1. Mavennet is a +1 to this
2. I believe that section can stay in the VCAPI CCG and continue incubation
3. Whenever we can settle on the language, hopefully reasonably soon.

[peacekeeper]

I agree with @mkhraisha , +1 to publishing a snapshot of the issuing and verifying parts and moving it to VCWG.

[OR13]

-1 to excluding the holder api ("create presentation"), otherwise you can't test "verify presentation", without relying on external libraries... also, issuers are holders... they literally hold the credentials they issue, even if its only temporary.

If issuer supports revocation, we MUST include a GET endpoint for hosting the revocation lists (or status lists).

I'm generally supportive of the idea of a note, as long as it does not cover the "cross trust domain exchange" part, which has several contentious flavors that we should tackle separately from where we have strong alignment.

I believe there is strong alignment on:

"A backend API for Issuers / Holders / Verifiers".

I believe there is not strong alignment on:

"A way to deliver credentials from an issuer to a holder, or presentations from a holder to a verifier".

Things that would make me a -1 to the move:

• many references to other CCG drafts getting dragged along in an"informative or optional" way.
• excluding VC-JWT
• excluding holder api (ability to make singed presentations)
• including credentialStatus support without defining associated endpoints.

We've spent a lot of work developing conformance and interoperability tests for the traceability api (which is basically a superset of what is suggested), for reference:

• https://w3c-ccg.github.io/traceability-interop/reports/conformance/
• https://w3c-ccg.github.io/traceability-interop/reports/interoperability/

I Imagine there are probably a few cases where deviation has already occurred, possibly with improvements on "both" sides... I assume the VCWG can make breaking changes, is that correct?

[msporny]

-1 to excluding the holder api ("create presentation"), otherwise you can't test "verify presentation", without relying on external libraries...

The proposal includes the "create presentation" API.

I have updated the proposal to make this more clear by adding "The NOTE will specifically provide the VC API calls necessary for generating a Verifiable Credential, generating a Verifiable Presentation, verifying both a Verifiable Credential and Verifiable Presentation, and checking the status of a Verifiable Credential."

If issuer supports revocation, we MUST include a GET endpoint for hosting the revocation lists (or status lists).

This has been added to the proposal.

I'm generally supportive of the idea of a note, as long as it does not cover the "cross trust domain exchange" part, which has several contentious flavors that we should tackle separately from where we have strong alignment.

Agreed.

• many references to other CCG drafts getting dragged along in an"informative or optional" way.

I presume this would apply to the VP Request specification, the OIDC4VC specifications, and aspects of the Traceability Profile that do not overlap with the more narrow parts that are described in the now updated proposal?

• excluding VC-JWT

There is no proposal to exclude any format at present.

• excluding holder api (ability to make singed presentations)

Including the ability to make signed presentations was a part of the initial proposal, which is not explicitly stated in the proposal (but is now).

• including credentialStatus support without defining associated endpoints.

The endpoints (or a mechanism to retrieve the credential status) is in scope for the proposal.

I Imagine there are probably a few cases where deviation has already occurred, possibly with improvements on "both" sides... I assume the VCWG can make breaking changes, is that correct?

The short answer is "yes", but I expect many of us that are implementing will also be involved in the VCWG and will have a significant say in whether or not the breaking change is appropriate. For example, if someone that's not implementing VC API proposes to make a breaking change in a way that is not acceptable to many of the implementers, I don't expect the proposal to make the breaking change to survive.

[mavarley]

+1 to publishing a a note to the VCWG based on the above proposal (https://github.com/w3c-ccg/vc-api/issues/304#issuecomment-1265425599)

[msporny]

The VC API group discussed this on 2022-10-04 and came to consensus on requesting that a snapshot of the VC API be made as a NOTE via the VCWG (given the constraints discussed above).

[msporny]

Next steps are to create a version of the specification that can be snapshotted as a versioned-release of a Final Community Group Specification and then handed over to the VCWG.

[msporny]

We discussed this again on 2022-10-11 with a different group of people/implementers and there was consensus to publish. Additional items discussed were transferring the repository to VCWG and then forking it here (in the CCG) to continue working on the VC API. Updates to the NOTE will be published on a periodic basis depending on agreement between VCWG and CCG.

[msporny]

There is now a PR #320 to resolve this issue. This issue will be closed once the VCWG publishes a Draft NOTE of the specification.

[msporny]

The VCWG decided that it had too much on its plate, some VCWG Members were hostile to VC API being published, and for those reasons, did not adopt the work item for publication during the VC v2.0 WG Charter. The VC API is, however, being used to power many of the test suites in the VC v2.0 WG and so we are gathering implementation feedback through that mechanism.

Closing this issue as a snapshot of the VC API will not be published during this iteration of the VCWG.