Add support for proofChain to VC API POST credential/issue endpoint

[aljones15]

A credential issuance endpoint can be posted to multiple times with initially an unsigned credential and then later a signed credential which will have a new proof added to the VC which could use the proofId and previousProof options.
https://w3c-ccg.github.io/vc-api/#issue-credential

The schema for POST credentials/issue should have an optional proof property

the options object should now have optional options previousProof String or Array or proofId for specifying a proofId for a proof.

[dlongley]

+1 to most of this proposal.

the options object should now have optional options previousProof String or Array or proofId for specifying a proofId for a proof.

This is the only part that give me heartburn, since the issuer endpoint may be attaching more than one proof or there may be more than one previous proof, and these options might be insufficient / mismatched with the requirements. It might be better for proofId to simply be auto-generated for each proof and that every previous proof that the client submits in the credential be included in previousProof. We should figure out if we need more complexity than this or not in what we standardize (with, of course, individual implementations continuing to be able to add custom options as it makes sense).

Other considerations that we would want to highlight would be how status interacts and whether there generally should be no new status fields added when there are existing proofs / status fields for these proof chain endpoints.

[PatStLouis]

question: should the issuer verify exiting proofs before adding a proof set/chain? It's not in the spec but this would make an issuer instance output invalid credentials...

[dlongley]

@PatStLouis,

should the issuer verify exiting proofs before adding a proof set/chain?

No, I don't think it should do this -- and I think it's on the client if it sends something to an issuer endpoint that will produce something invalid. There are many ways "invalid" (in some sense) output could be generated due to configuration issues and other problems and, IMO, we can't and shouldn't try to patch them all by pushing all the various responsibilities to every component/endpoint.

[TallTed]

should the issuer verify exiting proofs before adding a proof set/chain?

I think this will likely depend on the deployment. Some will want to require it, others won't find it important. More business logic.