Revisit `SignatureInput` to allow custom signers to sign messages

[thehenrytsai]

SignatureInput currently requires private key. However there would be cases where private key is not available (e.g. key securing services, TPM, hardware-wallets).

A better model could be allowing a custom Signer to be injected, with perhaps a default implementation still expecting a private key as input.

[frankhinek]

@thehenrytsai Would it be possible to take this approach?

Rather than injecting a custom Signer that the DWN SDK would call instead of the default implementation...

• IF a private key isn't passed in authorizationSignatureInput to a given .create() method
• THEN an unsigned DWeb messages is returned

The developer would then have to handle signing with their "keystore" (TPM, secure enclave, hardware wallet, etc.) before passing the message to processMessage().

This would allow for UI interactions that might be asynchronous and require human intervention, such as signing with a hardware wallet.

[thehenrytsai]

Hey @frankhinek, definitely sounds reasonable in principle, though I would point out that it does mean that objects created by .create() methods could be "half-baked" (by design obviously) and allows the situation where some instance methods/properties can't be used, (ie. will blow up if called) due to absence of the authorization property.

[nearlyjuly]

Maybe there could be a parameter for the .create() methods with the default value being how it is now (private key was present and signatureMaterial has already been created), and then something like 'wallet' to read the private key/alg and create the signatureMaterial value within the method, plus a third option 'signer' where the signatureMaterial value will be passed in (as in it has been generated externally)

[thehenrytsai]

This is now done.