Please consider adding ED25519 to this list.

Cloudflare Workers recently added this non-yet-standard algorithm since it was requested so often by developers writing Discord integrations.

The operations they support are sign, verify, generateKey, exportKey, and importKey.

Support for this would be nice for folks wanting to write cross-worker-platform code with similar crypto support and performance characteristics.

I will bring this up with the webcrypto working group at W3C. It seems like a logical addition. We won't act prior to standardization though.

I applaud this overview. Thank you

As far as urgency goes, given my wishful target of supporting JWS formatted JWTs first the most important missing piece is SubtleCrypto.importKey jwk, spki, and pkcs8 format support for RSASSA-PKCS1-v1_5, RSA-PSS, and ECDSA keys. Immediately followed by ECDSA verification, then encryption (AES-GCM, AES-CBC).

I would also like to note that importKey for HMAC is only partially complete as the jwk format is not supported yet, only raw.

@littledivy I'm working on a deno-specific publish and build process for jose - that is pure TS export and autopublish to https://deno.land/x/jose.

While the implementation is incomplete it is not possible to use the package without --no-check due to the missing types.

Would it be possible to make it so that the WebCrypto interface would be complete and type-defined whilst the actual missing implementations simply throwing throw new DOMException("Not implemented", "NotSupportedError")?

It's global type interfaces such as HmacKeyAlgorithm, RsaKeyAlgorithm, EcKeyAlgorithm, RsaHashedImportParams, AesKeyGenParams completely missing as well as importKey being hardcoded to format "raw" at the moment rather than the KeyFormat enum that's making my universal bundled module not work when default type checking is enabled in deno.

In order for an implementation to be portable the types should follow lib.dom.d.ts from TS.

@panva Yeah missing types can be annoying but I think that they should match reality. cc @lucacasonato

btw HmacKeyAlgorithm, RsaKeyAlgorithm and EcKeyAlgorithm should be fixed in #11738

also lib.dom.d.ts too has harcoded "raw" in importKey while KeyFormat is declared but not used in the decl

I would very much prefer the types to be complete to allow for portable implementations, that went out of their way to be fully built using TS and prepared to be consumed in Deno in through deno.land/x, to be used without having to instruct users to disable their precious type checking.

ad importKey, that would appear to be a mistake on lib.dom.d.ts part, see https://www.w3.org/TR/WebCryptoAPI/#subtlecrypto-interface

it has little impact tho since they have an overload for each of the enum values.

@seanwykes let me know if you need a tester, as there's likely not much else I can help with when it comes to crypto, but I have at least have become a sponsor of the project 👍

@oles thanks for the offer, it'll be great if you can test #13013 - the PR includes JWK for EC and RSA - you can find the source branch here if you're ok with building deno, otherwise, let me know.

I've done some preliminary testing of RSA-PSS JWK and signed JWT using jose.

@seanwykes @oles needs P-256 ECDSA to sign an ES256 JWT. I already know the sign/verify operations work fine in jose, its just the key material imports that are missing for JWS/JWT to kick in and be usable.

@seanwykes @oles needs P-256 ECDSA to sign an ES256 JWT. I already know the sign/verify operations work fine in jose, its just the key material imports that are missing for JWS/JWT to kick in and be usable.

So should be ready to go, the JWK key imports are already implemented in #13013.

@seanwykes nice. In case you want to run the full suite of jose tests under Deno, this is how you might do that.

git clone --depth 1 --branch v4.3.7 https://github.com/panva/jose.git
cd jose
deno test --reload --jobs --allow-net --allow-read test-deno # replace deno with your local build

At the moment, with deno 1.16.4, the results look like this: test result: FAILED. 73 passed; 73 failed

@lucacasonato the table is lacking SubtleCrypto.importKey breakdown by format value. It would appear importKey is almost done when that's not the case.

Updated :-)

@panva success over at #13013 with both key import and signing!

Thank you for the pointers and the library, and thank you @seanwykes for your work on this - let me know if there's something more you'd like for me to test or help out with 👍

@panva JOSE test suite on current main branch: test result: FAILED. 100 passed; 46 failed.

ECDSA & ECDH imports / exports are coming very soon.

@lucacasonato I was checking that yesterday, great progress! much props to yourself, @seanwykes, @littledivy and anyone else participating in the effort.

I'd like to think the jose test suite is a good interoperability resource in addition to the web platform tests.

~98.1% of the WebCrypto APIs are now part of Deno v1.18.0 🎉

Thank you to @seanwykes and everyone involved in this nearly 6 month long effort!
Let's open new issue trackers for pending features (like p512 curve and non 96 bit ivs). Closing :-)

Let me join in the congratulations. @littledivy @seanwykes @lucacasonato thank you for these amazing efforts!

From a pending features perspective (JOSE completeness-wise) I'm looking at general P-521 support, P-384 ECDH. It'd be great to plan for Curve25519 and Curve448, either through adding this draft support or following Node.js and CF Workers in adding the NODE- prefixed versions until said draft is adopted as an official extension.

And here's my personal thank you to @littledivy, @lucacasonato and @bartlomieju for your patience and technical guidance for a Deno / Rust newbie. I've learnt a lot from you guys!

I have created an issue for P-521 support (#14766) and another for deriveBits which fails with P-384 key (#14765).