Should Solid project adopt the @trust/webcrypto library about cryptography-and-security

[RubenVerborgh]

Does that help clarify?

Thanks, yes.

Agree with your proposal for @peculiar/webcrypto.

[RubenVerborgh]

A couple of questions to better understand the need for webcrypto:

• Am I correct that we do not need webcrypto in the browser, because they have a native implementation?
• Do we still need it in Node, given that Node has a crypto library which covers the same functionality?

Can't we just switch to Node.js shims that delegate to Node crypto? cfr. https://npms.io/search?q=webcrypto

[dmitrizagidulin]

@RubenVerborgh excellent questions.

Am I correct that we do not need webcrypto in the browser, because they have a native implementation?

Correct, yeah. The webcrypto shims are just for the Node.js side (and they all use Node's native crypto under the hood), to enable isomorphic libraries that use the same code in the browser and on the server. (That said, implementation coverage of the WebCrypto API is not uniform across all browsers, so it's the usual situation of - sometimes you need polyfills in certain browsers.)

So there's two main questions here:

1. Does the Solid ecosystem need some kind of WebCrypto shim? and,
2. If yes, should it be the @trust/webcrypto implementation, or some other one.

Here are my thoughts on this:

Does the Solid ecosystem need some kind of WebCrypto shim?

I would recommend - yes. As long as the Solid ecosystem uses both Javascript in the browser and Node.js or TypeScript on the server, AND we do anything with cryptography, there is considerable advantage to writing middle and higher level code on top of the WebCrypto API, and being able to run it isomorphically. This is a conclusion that both Solid and many other projects have come to.

So, currently, the JOSE library that Solid uses is isomorphic, and is used in all auth-related libraries, browser side and server side.

If yes, which WebCrypto shim library should Solid use?

So actually, I would recommend against @trust/webcrypto at this point in time, and would recommend that Solid switches to the @peculiar/webcrypto implementation (which looks like it was inspired by @trust/webcrypto, but is more actively maintained, and is rewritten in TypeScript).

Up until recently, the isomorphic-webcrypto package used @trust/webcrypto as a server-side shim. And all the other projects that I've encountered in the wild just used isomorphic-webcrypto.
But now I see that isomorphic-webcrypto switched its dependency and uses @peculiar/webcrypto on the server side instead. And I think we should follow suit.

Does that help clarify?

[robmccoll]

It seems like as straightforward of a wrapper as it could be and covers more than just "these were the algorithms we needed - everything else TBD". @peculiar/webcrypto-core does a good job of validating all of the inputs and not just passing things straight through to node's crypto implementation blindly.

[dmitrizagidulin]

This issue has been resolved -- the 4 Solid libraries that were using @trust/webcrypto have been updated to use isomorphic-webcrypto instead.
(Also, those libraries will be deprecated going forward anyway.)
Closing this issue.