Should Solid project adopt the @trust/webcrypto library

[dmitrizagidulin]

Consensus: Solid project should instead switch over to using the @peculiar/webcrypto-core library, which is a drop-in replacement for @trust/webcrypto, and is better supported.

---

Original issue: Should Solid project adopt the @trust/webcrypto library

One of the dependencies used by many of our crypto-related libraries is the @trust/webcrypto package. It's used in the jose lib (and through it, in auth-solid-client), as well as in the oidc-rp lib.

The problem is this: @trust/webcrypto has been archived, and is no longer actively maintained at that original repo. I've always figured we'd get around to deciding its fate eventually, but since an external developer brought up this issue in https://github.com/solid/oidc-rp/issues/26, I think we should have this discussion.

It's a good library, and is used by several non-Solid groups (such as Digital Bazaar in the minimal-cipher lib), and recently the larger Self-Sovereign Identity community has expressed increasing interest in it.

The decision we have before us is this:

Should the Solid project step forward to maintain the webcrypto library?

Reasons to adopt it:

• It's used throughout our authn stack, and will become even more useful once we get into features like DIDs and encryption.
• Adopting it will let the Solid project have a larger degree of control than if it's maintained by another group

Reasons not to adopt it (and let some other group pick it up):

• Time / developer resources
• I've talked to a couple of groups that are interested in taking on the task if Solid doesn't.

cc @jaxoncreed @pjworrall @justinwb @michielbdejong @kjetilk @robmccoll and whoever else wants to join in this discussion.

[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?

[RubenVerborgh]

Does that help clarify?

Thanks, yes.

Agree with your proposal for @peculiar/webcrypto.

[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.