Importing an Identifier

[atz3n]

Hell again,

I have a question on how to correctly import an identifier?
I tried the following, but this seems not to work properly:

let createdIdentifier = await agent.didManagerCreate();
createdIdentifier = (await agent.didManagerFind({})).filter((id) => { // get identifier with private key
    return id.did === createdIdentifier.did;
})[0];
console.log(JSON.stringify({ createdIdentifier }, null, 2));
/*
{
  "createdIdentifier": {
    "did": "did:ethr:rinkeby:0x0317b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39",
    "provider": "did:ethr:rinkeby",
    "controllerKeyId": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
    "keys": [
      {
        "kid": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "kms": "local",
        "type": "Secp256k1",
        "publicKeyHex": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "privateKeyHex": "a9cf6158bb1a66c380b708874af862ed5533a5c67e83223165cef5e13eae6cc998c60da6589a4615c6ae164cc63bfee0ba4616c929258375f84d1a6c770fe0ef1fa041c6d32b9942f180455b2cb4b06438a0686f86767a7450a5f061d2e678e6957dfd98df024bdc",
        "meta": {
          "algorithms": [
            "ES256K",
            "ES256K-R",
            "eth_signTransaction",
            "eth_signTypedData",
            "eth_signMessage"
          ]
        }
      }
    ],
    "services": []
  }
}
*/

await agent.didManagerDelete({ did: createdIdentifier.did });

const importedIdentifier = await agent.didManagerImport(createdIdentifier);
console.log(JSON.stringify({ importedIdentifier }, null, 2));
/*
{
  "importedIdentifier": {
    "did": "did:ethr:rinkeby:0x0317b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39",
    "provider": "did:ethr:rinkeby",
    "controllerKeyId": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
    "keys": [
      {
        "kid": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "kms": "local",
        "type": "Secp256k1",
        "publicKeyHex": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "privateKeyHex": "a9cf6158bb1a66c380b708874af862ed5533a5c67e83223165cef5e13eae6cc998c60da6589a4615c6ae164cc63bfee0ba4616c929258375f84d1a6c770fe0ef1fa041c6d32b9942f180455b2cb4b06438a0686f86767a7450a5f061d2e678e6957dfd98df024bdc",
        "meta": {
          "algorithms": [
            "ES256K",
            "ES256K-R",
            "eth_signTransaction",
            "eth_signTypedData",
            "eth_signMessage"
          ]
        }
      }
    ],
    "services": []
  }
}
*/

const retrievedIdentifier = (await agent.didManagerFind({})).filter((id) => {
    return id.did === importedIdentifier.did;
})[0];
console.log(JSON.stringify({ retrievedIdentifier }, null, 2));
/*
{
  "retrievedIdentifier": {
    "did": "did:ethr:rinkeby:0x0317b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39",
    "provider": "did:ethr:rinkeby",
    "controllerKeyId": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
    "keys": [
      {
        "kid": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "kms": "local",
        "type": "Secp256k1",
        "publicKeyHex": "0417b2e8b19004178ddce6245722f3ce1aa681493b19bab312eef566647c216f39ba00981ae679dc7ff5ebdb730bb2770bf5ff6baf150294fbff68f533e3eca38b",
        "privateKeyHex": "2fc26ffbed743d877f0f6ea49ffd7f2cbd913f7642fcf0239c67e7e6b0eb2d7d4efd9066eedeec3f03e8e3949ee1c5089532953c212336124de008acd82ed6500ec686cc08019e008f9f7421a3a594c07fc14b733d085eb2031cea4ffd50aa8ab48d01dad00b383fa3b364b3d5dfbd320a31e7c3fb5cbc6138293563ccaafdd51308c3dd80f201936d04c1695673b2b38ad671db7617247944fdc1a8fd1625ecd511ffb51df8a878ac5c2e1178ca60631e6409478b2a9e63ffc8cb766b0bd32c5b6898b085f53f9032690ae2de55eb9ee8750e30004e9d7393909ec2988aef9dc538923c1d2b3d3b98b79637324ba0a8f625e7699f33936a",
        "meta": {
          "algorithms": [
            "ES256K",
            "ES256K-R",
            "eth_signTransaction",
            "eth_signTypedData",
            "eth_signMessage"
          ]
        }
      }
    ],
    "services": []
  }
}
*/

The problem here is that the retrieved identifier somehow holds a different private key than the original created (and imported) one. Did I miss something?

Cheers

[mirceanis]

Great question!

The identifiers retrieved by agent.didManager*() methods list the keys as they appear in the database. In your case, you are likely using a SecretBox with your KeyManager in your setup, which means your keys are encrypted (as they should be!).

You can get the decrypted key by something like const fullKey = await agent.keyManagerGet({kid: createdIdentifier.keys[0].kid})
and then do createdIdentifier.keys[0] = fullKey before you call agent.didManager.import(createdIdentifier)

Important note

This works because the current implementation of @veramo/key-manager and @veramo/kms-local allow keys to be exported.
This functionality will likely be removed at some point from them.
Other implementations of AbstractKeyManagerSystem (that do not appear in this repository) use different key storage techniques and will not allow you to get to a private key.

We plan to add some convenience methods to allow you to import keys and identifiers more easily and also to bootstrap some identifiers from existing keys.

[atz3n]

thanks for the hint. It's a temporary solution for changing a DID controller. Since this functionality is not implemented yet, I've forked and extended the ethr did plugin. The problem is that the controller change is not reflected within veramo. To align the identifier with the contract state, I change the identifier manually and reimport them (at least this is what I'm trying to do :) ).

By the way will there be a mechanism to generate identifiers and export them including full keys after your mentioned changes are in place? We'd like to use veramo also for identifier creation, but only for creation and handle the private keys with another system. This also leads to another question. Is there a way to create unsigned VCs / VPs so that there is the possibility to create an endpoint that provides unsigned VCs / VPs? Another system which holds the keys could then sign these VCs / VPs and issue them. Maybe a second endpoint could also provide the functionality to import and store the signed VCs / VPs again.

[mirceanis]

A mechanism for splitting responsibilities does indeed exist, but is somewhat different than you describe.
What we have now is a way in which you can create several agents that split responsibilities but still act as one.

One agent handles key management / creation / signing, etc, another agent can act as credential storage and then a "frontend" agent would use the other two to perform the full operations.
The "backend" agents each use a subset of plugins relevant to their tasks and then expose some methods from these plugins to the frontend agent using the @veramo/remote-server. The "frontend" agent then uses the @veramo/remote-client plugin to connect to the backends and expose the relevant methods locally to the integrating app.
Then, to your app, it all looks like one agent, when in fact responsibilities are split.

This is what our agent-explorer demo does, actually. It connects to other agents and uses their exported plugin methods locally. I'll have to come back to you with some sample code that achieves this.

That being said, it sounds like the initial problem that you describe (the controller change is not reflected within veramo) is functionality that should be resolved along with the API for controller changes.
It seems to me that it should be enough to change the controllerKeyId of the IIdentifier for which you are changing controller (unless that's already what you are doing and running into blockers )

[atz3n]

interesting. Looking forward for some samples.

That being said, it sounds like the initial problem that you describe...

Yep, that's exactly what I want to do. I could achieve a first running workflow for that task today 💪

[mirceanis]

fantastic!
do you want to contribute a PR with this workflow or is it internal to your project?

We also want to implement this API, but we would also welcome contributions :)

[atz3n]

see #574 (comment) :)