Connect the Service to remote signers. Support remote key management.

[decentralgabe]

As the title states; demonstrate integration with remote keystores.

[andresuribe87]

The first thought here is that we should focus on ssi-sdk first. When we have an SDK that handles remote key generation and cryptographic operations, then we can use that to inform the design that we should follow for ssi-service. I've created TBD54566975/ssi-sdk#336 to track on that side.

[decentralgabe]

@andresuribe87 can this be closed?

[andresuribe87]

#420 addresses having and external KMS to store the service's keys. That PR doesn't address the ability to have external signers, nor to bring your own keys when creating an ION did (or any other did).

This issue is about supporting that.

[nearlyjuly]

Seems all good. So would it be on the user to specify first the storage (kms or other) and signer (remote or local)? As in, for DID creation ask first where the keys are to be stored or where existing keys can be found, for DID creation & credential creation ask the same plus which signer to use, and for only credential creation ask where the keys and the signer are (making it possible to provide one or both)?

[andresuribe87]

The signer is expected to hold the keys that they're using to sign with and never share them. So there isn't an expectation to separate storage and signer.

When you create a DID, you'll have to option of specifying that you want to sign yourself, with your own keys.
If you don't specify that option, then the service will generate the keys and they will never leave the boundaries of the service.

Any task within the service that requires signing will decide wether to sign inside the service (if the keys are available), or to defer signing to the external party.

@nearlyjuly , let me know if that makes it more clear.