APIs that perform signature operations (e.g. TransactionBuilder::execute) rely on the assumption that their invoker can supply a whole keypair, but this assumption is not valid in cases where users store their crypto-material within a key management system that adhere to the secure enclave principle (e.g. Hashicorp Vault, AWS KMS).

To enable these users (as well as other IOTA products that adhere to the aforementioned principle) to consume the SDK, either the existing APIs are changed or new APIs are introduced.

One possible approach would be to create a new trait AsyncIotaSigner that behaves like IotaSigner but in an async manner. Providing an implementation of AsyncIotaSigner for all types that implement IotaSigner, and in turn implementing IotaSigner for all key pair types, the existing API would support this use case without having to break.

The approach of relying on the IOTA Keytool is not a viable option, as it fails to support the targets not supported by the Keytool itself like browsers or mobile devices.