[proposal] Support sr25519 as signing algorithm

[trusch]

Is your feature request related to a problem? Please describe.
I want to use libraries from the ecosystem to build stuff on top of the KILT DID method. KILT is built on top of polkadot and the default signing option there is sr25519. KILT DIDs can also use ed25519 or ecdsa keys, but this is not the default case and nearly all KILT DIDs currently have an sr25519 authentication key.

Describe the solution you'd like
I'd like to see support for the sr25519 signing algorithm.

Describe alternatives you've considered
We could write the minimal feature set we need on our own from the ground up, but thats no real option.

Additional context
I came here from https://github.com/Sphereon-Opensource/SIOP-OID4VP which has a direct dependency to you.

[trusch]

I basically have a PR ready which would add support by including @polkadot/wasm-crypto as a dependency. Unfortunately this increases the build output size a lot (including this change the dist folder is 388KB).

Could this be considered to be included? I can open a PR if there is the possibility to get that merged!

[mirceanis]

This library is used by many projects in environments where wasm is not supported out of the box so we can't accept wasm-based dependencies, unfortunately.
Do you know of any JS implementation that can be used instead?

You might be able to still use this library for signing, as the signers can be provided externally.
Verifiers are still baked in, for now.

[ntn-x2]

Hi @mirceanis, jumping on this issue since we would REALLY need to somehow have a way to verify Sr25519 signatures using this library. So, is having a WASM-based dependency an issue for the whole library? Would there be a way to make this either a opt-in, or simply fail to sign/verify if the environment is not the right one?

[rflechtner]

From our experience, not all WASM is created equal, and with this particular library we haven't had issues with any environment we tried it in, including the browser, react-native, and node.js. There is also a recent pure js implementation (https://www.npmjs.com/package/@unique-nft/sr25519), but given that it's fresh off the boat I can't vouch for its security. That said, if including sr25519 verification is not an option currently, providing a way to plug your own verifiers, or at least to reuse decoding and verification logic not related to signature verification would be of great help to us.

[stale]

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.