PROPOSAL: delete verifyCredential operation

[OR13]

Its redundant to verify multiple credentials which is now supported by verify presentation.

this would also help avoid the confusion of "when do i verify a vc vs a vp"... short answer is... always use a vp.

Also aligns with CHAPI which uses VPs as a transport data structure.

[peacekeeper]

Hmm I don't really feel strongly about this, but I think both operations are justified, because

1. the VC data model spec also distinguishes between "verifiable credential" and "verifiable presentation", and to me it feels intuitive that the VC HTTP API supports both separately.
2. I think there may be use cases where you want to verify a VC, not a VP. E.g. VCs may be publicly hosted at some well-known URL, and you just want to download and verify them. Of course you can wrap a VC in a (proofless) VP just before calling the API, but that feels like an inconvenient and unnecessary extra step.

[OR13]

both options are legal... but thats not what matters... we are trying to build an HTTP API for VCs and encouraging folks to not use VPs to move credentials around creates harmful optionality.... and a complicated API with redundant paths.

I suppose we can keep adding optional redundant endpoints to the spec, for anything that is legal according to the vc data model... but I think thats not actually helpful to developers / businesses.

We need a minimal set of endpoints, that encourage best practices.

I think its an anti-pattern to expose a verification endpoint for credentials that does not hint at client authentication (with VPs).

[mprorock]

verifyCredential seems an implicit operation even if not always or often used

[msporny]

The group discussed this on 2022-03-29. @mkhraisha summarized the issue and suggested it was fine to leave verify credential route. @dlongley noted that having a separation here might be of value for -- if we're going to use an endpoint where we can turn off checking signature on presentation (verifyPresentation) vs. having an endpoint for just checking a VC might be useful. @TallTed noted that it should be allowed to just verify bare VCs w/o embedding them in a VP. @mkhraisha noted that we could make this an optional endpoint. @mprorock noted that if we have an endpoint for creating VCs, it would be strange to not have an endpoint for verifying VCs.

The group came to consensus that: The endpoint is useful and should be kept and is a mandatory endpoint.

This issue will be closed in 7 days if there are no objections.