Hi, thanks for your interest! I didn't review thoroughly but put one tiny bit of JSDoc definition feedback in case it's helpful to your branch.

Unfortunately this seems like a really huge jump and change for this library which is basically in "maintenance mode". The goals now are compatibility and stability (and of course security) but as you note there are several major breaking changes. (I'm also a bit worried that being compatible with WebCrypto browser-side would only encourage people to use it in insecure ways and/or leak their signing secrets to the client, etc.)

The value of this library at least in my opinion is that it's ± "finished" and can just keep getting used for its initial scope. For changes this major I would probably just recommend starting an alternate library that can progress more ambitiously if there's need for it. I sort of "inherited" (= got left holding the bag 😂 xref #36 but it's fine) this library from its original author, and while I can't speak for TJ my guess is nobody would mind there being more and newer alternatives.

I'll leave this PR open for a little while in case you or others want to chime in, but I just wanted to be up front about unlikely to accept these changes here to this package.

@natevw My goal was to make this a first step towards full Web Crypto compliance (using the crypto global instead of the Crypto API), so that this package could be used on other runtimes like Bun, Cloudflare and/or Deno as well

• https://bun.sh/docs/runtime/web-apis
• https://developers.cloudflare.com/workers/runtime-apis/web-crypto
• https://deno.land/[email protected]?s=SubtleCrypto

I know this PR has some breaking changes, but that's because the Node Crypto API is totally not standardized, whereas the Web Crypto API is 🤷‍♂️
These changes are also acceptable imo as going async is something that's widely happening in the community and most use-cases probably were with a string secret

Yep, see https://github.com/nexdrew/cookie-signature-subtle via #49 (comment) which looks like it'd give the same functionality without causing the backwards compatibility concerns here. So assuming that's a good path forward for these kinds of use cases, I'll decline this PR here — again nothing inherent wrong with the code and do appreciate the contribution attempt, just a bit more of a maintenance jump than I'm comfortable tackling on this repo.

@natevw If you want I can look at the other lib and keep the API the same