[proposal] Enable experimental support for `Ed25519Signature2020`, `JsonWebSignature2020` on `credential-ld`

Currently, did-jwt can resolve JWT proofs of JSON credentials along with credential-w3c. There’s context for W3C security suite, but it’s marked as unstable.

Community group reports have reached at a consensus, which can make way to start enabling on richer credential formats, such as JSON-LD, starting with credential-ld.

I suggest the following steps:

Ed25519Signature2020

• Write an implementation of @digital-bazaar/ed25519-signature-2020 (not @transmute/ed25519-signature-2020 as it’s not actively maintained) in the scope of a VeramoLdSignature extension.
  • VeramoLdSignature stands for the base signature class.
  • The signature implementation should live in src/suites .
  • Provide required context under src/contexts
  • There’s already provided context in did security suite v3 represented, which is marked as unstable, but we can enable it with the with the current standing suite spec and move it to a separate json file.
  • Might need to provide 2020 credentials context as well.

JsonWebSignature2020

• Write an implementation of @transmute/json-web-signature-2020 in the scope of a VeramoLdSignature extension.
  • Follow along Ed curve steps from above but with JsonWebSignature2020 , JsonWebKey2020.

@mirceanis @italobb Let me know your thoughts.

[DaevMithran]

@Eengineer1 @digitalbazaar/ed25519-signature-2020 has a few issues in typescript support when I tried integrating it, So I am using @digitalcredentials/ed25519-signature-2020 which is a fork of @digitalbazaar/ed25519-signature-2020 with a better typescript support for the integration

[Eengineer1]

@italobb Agreed and thanks for mentioning.

In the end, if the decision boils down to having a better supported fork that usually has better compatibility, let’s just go with this.

As flagged, it’s about enabling experimental support first and then moving on to a well tested version.