Add support for proof chains 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.

[msporny]

The group discussed this on the 2025-01-14 telecon:

One approach is to add proofs synchronously (different groups), instance configured to add all proofs (client authorizes all signatures to be put on there), how it acts can be externalized in another system -- not compositional -- maybe we want a different endpoint for this -- open question for how this should fit into VC API. @jandrieu noted that use cases were going to be written for proof chains and proof sets -- if we have use cases, what are real world thing here, that might help us navigate technical choices. @dlongley agreed with that, and we have implementations w/ sets w/o chains -- chains are a subset of proof sets... configs are empowered w/ different types of keys to generate proof sets -- config has capability to contact key signing service to use different keys to generate full proof set when VC is issued. We have that piece (for sets), for chains (we don't quite have the capability). If setup is such that you have keys that are part of chain, can do signing one after the other. @jandrieu noted we don't have those use cases written up -- proof sets are about having multiple signatures by same issuer for cryptographic flexibility. The group identified the following use cases (to start):

• Proof set with one issuer generating multiple proofs to enable the holder to have cryptographic flexibility when they go to present a VC (adding ECDSA, EdDSA, and BBS signature to a single VC).
• Proof chain to have multiple issuers that are expected to sign in a specific order.
• There are use cases for proof chains and proof sets that might not fit here.

A PR should be raised that notes that an issuance instance can be configured to clear existing proofs and always generate a new single proof, generate more than one proof in parallel (proof sets), generate more than one proof in series (proof chain), or any variation thereof (hierarchical proofs) based on use case needs.