Improve Key Management in DID Import [proposal]

[DaevMithran]

Is your feature request related to a problem? Please describe.
The DID import api currently imports a DID with all keys specified in the argument, I propose to add the features mentioned below

1. Be able to handle existing keys
2. Bootstrap a DID from provided keys, this is useful for did:key and few others when you only know the keys but don't want to compute the DID beforehand
3. Update an existing DID (re-import), a DID in the wallet could be updated externally we should sync any changes made to it on request

Describe the solution you'd like
Extract the list of keys required for the DID import, by resolving the DID and using extractPublicKeyHex util function. Now if the publicKeyHex is already in the wallet we should skip the key import step for it. But making sure we validate all the required keys are passed in the request.

[pauldesmondparker]

Has the code changed re: this issue changed since Jan 2nd?

1. didManagerImport doesn't touch the provider, so nothing will go onchain. It also doesn't affect the keyManager, so it is not a route to add keys to the key manager EDIT (not true). Perhaps removing this function's effect on the keyManager might fit your purpose.
2. I haven't used did:key before, but shouldn't didManagerImport do this already? Maybe I'm not understanding what you mean by compute the DID.
3. This would be convenient and I've thought this myself. To restate so I'm not inadvertently mangling your idea: Sync the state returned by a call to resolveDID with the DID stored in the local wallet.

What happens when the local state of the Identifier has more information than the provider state? Is the local information lost? This would be analogous to a git pull from a remote when you're added a commit that diverges from the remote. How should the merge be handled? This seems prohibitively complicated to be handled by Veramo. Are you only interested in a destructive pull, i.e. git fetch && git reset --hard origin/master :)

AFAIK, there is no Identifier version management that would formalize the cases. In did-document-metadata there is nextUpdate which points to a more recent version of the Identifier, but strangely (to me) no field (mandatory or not) that points to the previous version of the Identifier. I could imagine scenarios where two autonomous DID controllers may want an Identifier update (push) to fail if the remote state has diverged from their local history.

[pauldesmondparker]

At the risk of hijacking this issue and sending it in a direction other than intended by the OP.

I feel like the operations of the DidManager are not currently sufficiently orthogonal to each other to allow the composition of operations that would allow: the local recreation of an Identifier resolved from a provider where particular keys are not controlled by the local keyManager.

Note

Maybe this is intentional. The DidManager doesn't hold a perfect copy of the Identifier locally, it's just the did, alias, provider, and a pointer to the controller key; and a bundle of keys and services.

Removing a key (didManagerRemoveKey) from an Identifier stored on a did registry will currently throw if the key does not exist on the local Identifier. This can be caught and ignored, or (hackishly) we can add the key to the keyManager with a spoofed private key so no error is thrown (but then we have keyManager cleanup to do afterwards).

Strangely, didManagerAddKey, unlike didManagerImport, does not add the key to the keyManager.

The following is a matrix of the systems affected by different didManager operations:

[pauldesmondparker]

For reference: requiring more orthogonality in issue #1373.