Open Sshovon opened 2 weeks ago
So for did:key it doesn't really matter as only the key is encoded in the did, not the whole verification method.
I think once we switch to 0.6 we should change the default resolved key to Ed25519VerificationKey2020 (or even better MultiKey/JsonWebKey).
However i think you should be able to use any verification method we support and which we can extract the right key instance from for issuance. So if you want to sign using EdDSA, we support Ed25519VerificationKey2018, Ed25519VerificatiomKey2020, JsonWebKey, and MultiKey. If not, there is some code still that doesn't use the correct transformation logic -- mainly for JSON-LD suites which we should fix
Yes, JSON-LD
issuance doesn't work properly using Ed25519VerificationKey2020
. Looking forward to the 0.6
release. Thanks for the quick reply. Really appreciated.
Let's keep this open to track the status
During
did:key
creation, we currently have the option to specify theKeyType
, which by default usesEd25519Signature2018
signature suite during did document generation. AlthoughEd25519Signature2020
has been added as a signature suite in the latest stable release (0.5.12) of Credo, there doesn’t appear to be an option to create a DID using that. Could anyone confirm if this understanding is correct, or if there are any available options to achieve this?Also if we have the
did:key
withEd25519Signature2018
, can we use that DID to issue a credential with proofTypeEd25519VerificationKey2020
?