Add proof type issue/present option

[clehner]

Signature suite Ethereum EIP712 Signature 2021 (proposed work item: w3c-ccg/community#194) does not define a new verification method but only a signing method (proof type), and is meant to be used with existing verification methods EcdsaSecp256k1VerificationKey2019 or EcdsaSecp256k1RecoveryMethod2020. For proof creation with vc-http-api, the verificationMethod option of the issue/present credential options is then no longer sufficient to identify the type of proof to create, since there is not a one-to-one correspondance of verification method type to proof type. This PR adds a type option for use in situations such as this where there is more than one type of proof that could be issued.

Edit: relevant issue #47.
This also could be useful if one wants to choose between using e.g. Ed25519Signature2018 or Ed25519Signature2020 when the issuer/holder is using did:key.

[msporny]

Now the question becomes... why is type a fully qualified URL and assertionMethod is not. :)

We could go two ways on this -- include an @context (probably overkill), or require full URLs in options (probably annoying).

[clehner]

Amended to use the compact form, for consistency with the other options and existing conventions for proof objects.

[msporny]

Same issue as above.

[clehner]

Amended to use the compact form, for consistency.
https://github.com/w3c-ccg/vc-http-api/compare/322fba6..173c26b0df3ca1a1406f7b8d4469ef5f15b3afcb

[clehner]

@OR13 I think in #47 you were suggesting to not use a key of one type with multiple signature suites; I wonder if that still your opinion, or do you think this is a good approach?

[OR13]

@clehner I am no longer certain that proof.type -> verificationMethod.type should be a 1-1 binding, but this work item is probably not the place to sort this out... from a security perspective, its possible to verify a VC where this is not a 1-1 mapping, I tend to treat that as the rule of law....