Option to override signing implementation

[emlun]

Hi! My application generates JWTs whose proof keys are hardware-bound. Currently, this library only works with private keys either held in application memory or as CryptoKeys in browser memory - either way, both kinds are keys held in software. I therefore made a local fork with a small patch to add an escape hatch to invoke an external signing procedure - in this case backed by this proposed WebAuthn extension which enables signing arbitrary data using hardware-bound keys. The same escape hatch could also be used to connect to any other kind of external key store such as an OS keychain or a remote server.

Would you be interested to adopt this feature upstream? I have a cleaned-up branch with tests and docstrings ready to submit as a PR if so.

[panva]

Hi @emlun I would not be interested in custom signers per se, no, at least thats my knee-jerk reaction. But I would be interested in the implementation of the signFunction you have with the WebAuthn extension to see if that could simply be built in.

[emlun]

Heh, interesting 🙂

First off, the extension is currently at the proposal stage with no support in browsers apart from my own experimental Firefox build. So it'll be a while (~years, probabl) before this is generally available, assuming the WG even accepts it and browsers agree to implement it (all WebAuthn extensions are optional to implement).

But let's say all that works out. At its core, all that really needs to happen inside the signFunction is a call to navigator.credentials.get with a publicKey argument containing sign extension inputs. Once that promise resolves, the signature can be extracted from the authenticator extension outputs (this requires parsing CBOR) and returned as the signFunction result. The library would need to set all the WebAuthn inputs, including constructing the sign extension input. I suppose all of that could be encapsulated in some new private key format that contains all the necessary settings, similar to a JWK (the simplest possible approach would be to just take a raw PublicKeyCredentialRequestOptions object as the key representation). The extension is still in development, so all the details like key handle representations aren't quite nailed down yet, but I think it should be up to the application to construct those anyway, rather than needing to support every possible algorithm and their input encodings in the library.

My signFunction implementation is here: https://github.com/wwWallet/wallet-frontend/blob/bf0324c68ec5a71eeed2a52c763e3f34310f132c/src/services/keystore.ts#L1458 . As you can see, the makeWebauthnSignFunction function embeds a fairly complex "UI state machine" in the Promise in order to pass progress notifications back and forth between the caller (which manages the React UI) and the keystore layer (which generates the WebAuthn inputs). At first I was about to say this would be hard to get away from because every WebAuthn ceremony involves user interaction with browser dialogs, which should probably be accompanied by appropriate feedback in the website UI, but I think most of that can actually be stripped away - this particular implementation is mostly an overengineered internal retry loop, which I suppose could just as well be extracted to the view layer instead.