Improve key/suite/algorithm choice when creating VC/VP

[mirceanis]

Background

It is very ambiguous exactly what key or algorithm will be used when creating a credential or presentation in Veramo 3.1 (&next).

Some keys can be used to sign using multiple algorithms / signature suites. For example, a Secp256k1 key can be used for: ES256K(jwt), ES256K-R(jwt), EthereumEIP712Signature2021(JSON), EcdsaSecp256k1RecoverySignature2020(JSON-LD), EcdsaSecp256k1Signature 2019(JSON-LD), and a few others.

Some issuer DIDs have multiple keys that can be used for signing. If a new key is added specifically to sign new credentials, it won't automatically be used, especially if another managed key of the same type is found first.

Proposal

I propose the following changes to the createVerifiable*() method arguments:

• proofType will describe the algorithm (e.g. EdDSA, Ed25519Signature2018), instead of jwt/lds/712
• keyRef will specify either the id of the verification method from the issuer DID document, or the internal kid known by @veramo/key-manager/@veramo/did-manager

The algorithm for creating proofs would change to:

• inspect the credential payload and extract the issuer DID
• first filter the keys associated with that DID by keyRef, if one is supplied,
• then filter the keys based on the matching proofType.
• If no key is left after filtering, throw an error.
• decide which plugin (jwt/ld/712) can generate the proof and call it with the filtered parameters.
• if an error is thrown by the called plugin and there are other keys/algorithms left after the filters, try the next one.

Implications

• DID document of the issuer must be resolved when the keyRef does not refer to an internal key ID
• Since the implementations of JWT vs JSON-LD vs JSON proofs are provided by different plugins, the credential issuer plugin must also maintain a list of algorithms and their corresponding plugin implementation.
• Creating JSON-LD Presentations containing non LD credentials may fail because of LD reasons.
• The key metadata provided by KMS implementations becomes very important to decide if an algorithm or proof type is supported by a key. If this metadata is not available, some heuristics can be hardcoded, based on known key types.

[mirceanis]

removing this from milestone v4 since it can be done as a feature release, without a breaking change

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.