Proposal: add crypto implementations as optional import

[cre8]

To make the usage easier for developers, I would suggest also to publish an implementation for the signet and verifier functions like key generation, hashing etc.

I would like to include it in the src folder and not an example folder so a developer can easily import and use it.

We are not forcing someone to use it, but we offer a challenged implementation that is ready to be used in the browser or in nodejs.

[cre8]

Since we are planning to split it up in multiple packages, we could create two implementations that can be used and can be used on demand. Then everyone should be happy

[lukasjhan]

That's good idea :)
How it's done is very simple. We just recover the removed crypto functions in #60. crypto.ts, crypto-broswer.ts

[berendsliedrecht]

I think providing some default crypto can be very nice. Deciding which algorithms to support might get a bit more complex.

I suggest the following:

packages

• @sd-jwt/crypto-nodejs
• @sd-jwt/crypto-react-native
• @sd-jwt/crypto-browser

Algorithms

• SHA2-256
• Ed25519
• ES256

But just to be clear, these should match an interface provided by the core library and users can provide their own cryptography.

[cre8]

@berendsliedrecht yeah, I would go with the default ones that are supported natively by Node or the browser. For me the EC based ones would be enough since RSA is not the way to go today.

[lukasjhan]

Agreed.

Supporting React Native is also good idea. (Might need to check the Expo)

[berendsliedrecht]

@berendsliedrecht yeah, I would go with the default ones that are supported natively by Node or the browser. For me the EC based ones would be enough since RSA is not the way to go today.

I think supporting all the native ones is a good goal, but quite a bit. Also, it is not consistent between platforms. We could diverge them, but I think it would provide a nicer experience for all the packages to have the same functionality and keep it limited at a start. Especially with key management, users will likely already have some mechanism for that, so I don't expect heavy usage of these packages.

[cre8]

@berendsliedrecht yeah, I would go with the default ones that are supported natively by Node or the browser. For me the EC based ones would be enough since RSA is not the way to go today.

I think supporting all the native ones is a good goal, but quite a bit. Also, it is not consistent between platforms. We could diverge them, but I think it would provide a nicer experience for all the packages to have the same functionality and keep it limited at a start. Especially with key management, users will likely already have some mechanism for that, so I don't expect heavy usage of these packages.

I would prefer to start with a "mvp" approach, giving people an implementation for EC for Browser, Node and React Native, and for hash maybe SHA 256. Of course we will not limit it to this, but having this generic interface allows everyone to append one more crypto implementation.
With the minimal approach we have to be sure that we provide a challenged implementation to avoid bad PR ;)

[lukasjhan]

Which way do you prefer?

1. using platform's crypto features (like node:crypto from nodejs, subtle from browser etc.)
2. using pure js implementation like noble-curve

[cre8]

I am a fan of native ones because there is less third party dependency. We already have them implemented in the example so it's not big deal to finish this task (for now).

In case we see problems with the implementation we can quickly add noble-curve.

[lukasjhan]

Okay Let's try native one first :)

[berendsliedrecht]

Native has my preference as well. That way it would also be easier to add potential support for bun or deno and what not.

[lukasjhan]

I'll work on the nodejs and browser first :)

[cre8]

Closing this since it got implemented in #106