Default verificationMethod

[clehner]

DIDKit/ssi currently fails this VC HTTP API test:
https://github.com/w3c-ccg/vc-http-api/blob/b4df10dfdce98b453a2333e7ec1728a10bcc54d1/packages/vc-http-api-test-server/__tests__/issueCredential.spec.js#L72-L85

6. The Issuer's Issue Credential HTTP API MUST reject if the value of "options.verificationMethod" in the body of the POST request does not exist.

That test requests issuing a verifiable credential with linked data proof option verificationMethod: 'foo', and we are supposed to reject this. A solution would be to require that the verificationMethod value is a URI, or at least looks like it might be a URI. verificationMethod may be a URL, or a DID URL, and we see both in this example:
https://w3c.github.io/vc-data-model/#example-2-a-simple-example-of-a-verifiable-presentation

We should also consider what to do when no verificationMethod option is passed in a PresentCredentialOptions or IssueCredentialOptions object. Currently we construct the proof anyway. But this means the resulting proof cannot be verified unless the verifier knows the verificationMethod URI separately tand passes it in the verification options. The description for the verificationMethod option in VC HTTP API says (https://github.com/w3c-ccg/vc-http-api/blob/b4df10dfdce98b453a2333e7ec1728a10bcc54d1/docs/vc-http-api.yml#L226-L228):

The URI of the verificationMethod used for the proof. Default assertionMethod URI.

I think that description implies that if the verificationMethod option is not passed in the issue request, the implementation should pick a verification method that has an assertionMethod verification relationship with the DID subject. i.e. assuming the VC issuer is a DID, resolve the DID document, enumerate the verificationMethod array, and pick the first value for which we have the corresponding private key. If the issuer is not a DID, the verificationMethod URI would need to be passed in to the issue options, or the operation would fail, unless/until we have an idea of what to do in that case. I don't think we need to support creating proof objects where the verificationMethod property is missing.

[wyc]

Agreed on avoiding implicit substitutions and selections, and simply failing if a parameter is un/underspecified. Sounds like a good approach.

[clehner]

Reopening, as it seems that it is expected by VC HTTP API that DID resolution does happen during issuance, to check the verification relationship (between the issuer and the requested verification method and proof purpose) or to pick a default verification method and proof purpose.