feat!: allow to import created dids (and remove legacy publicDidSeed)

[TimoGlastra]

Dependant on #1286.

This removes the publicDidSeed and publicDid properties from the wallet / agent config and instead require you to import the key / did document into the agent yourself. This is useful if you e.g. have an existing endorser did and want to start using it in AFJ.

If you've previously used the publicDidSeed property you would only need to call the storeCreatedDid property, as the key will already be in the wallet.

I had to find a workaround for indy-sdk that only allows signing ledger requests if you created it using an indy did, not using a key created using createKey. This limits how we only manage keys using the wallet and dids are managed on a higher leverl. To get around this I copied the serialization logic from indy to get the input for a ledger request signature and have implemented it in AFJ. This way we can just call the sign method from indy-sdk instead of the signRequest method and get around this limitation. This means we are not using the dids from indy-sdk at all anymore, but just the lower level key/crypt functionality. I'm quite happy with this change, as it removes one of the last indy-baked-into-core functionalities we have together with #1286 and #1320

BREAKING CHANGE: this PR removes the publicDidSeed and publicDid from the wallet and agent config. These properties were very focused on indy dids, and should now be managed through the DidsApi. If you want to import an existing (endorser) did into the wallet you can do so now using DidsApi.sotreCreatedDid and agent.wallet.createKey.

An example script to import a key and fetch + store the did document (determine for yourself whether this is 'safe'). Make sure to replace <namespace> with the core indyNamespace that you also use for your pool config.

  const key = await agent.wallet.createKey({
    keyType: KeyType.Ed25519,
    privateKey: TypedArrayEncoder.fromString('yourverysecureseed'),
  })

  // did is first 16 bytes of public key encoded as base58
  // if you already know the did, you can hardcode it here as well
  const unqualifiedIndyDid = TypedArrayEncoder.toBase58(key.publicKey.slice(0, 16))

  // resolve and store the did document in the wallet so it can be used
  const didDocument = await agent.dids.resolveDidDocument(`did:indy:<namespace>:${unqualifiedIndyDid}`)
  await agent.dids.storeCreatedDid({ didDocument })

  return unqualifiedIndyDid

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (main@dc60acb). Click here to learn what that means.
The diff coverage is 61.76%.

@@           Coverage Diff           @@
##             main    #1325   +/-   ##
=======================================
  Coverage        ?   75.93%           
=======================================
  Files           ?      692           
  Lines           ?    16569           
  Branches        ?     2818           
=======================================
  Hits            ?    12581           
  Misses          ?     3984           
  Partials        ?        4           

Impacted Files	Coverage Δ
packages/core/src/agent/AgentConfig.ts	86.36% <ø> (ø)
...ages/core/src/modules/dids/repository/DidRecord.ts	100.00% <ø> (ø)
packages/core/src/types.ts	100.00% <ø> (ø)
...ckages/indy-sdk/src/dids/IndySdkSovDidRegistrar.ts	12.50% <9.52%> (ø)
packages/core/src/modules/dids/DidsApi.ts	59.61% <45.83%> (ø)
packages/indy-sdk/src/wallet/IndySdkWallet.ts	30.41% <46.15%> (ø)
.../core/src/modules/dids/repository/DidRepository.ts	69.69% <50.00%> (ø)
...ages/core/src/wallet/error/WalletKeyExistsError.ts	50.00% <50.00%> (ø)
...ndy-sdk/src/ledger/serializeRequestForSignature.ts	83.33% <83.33%> (ø)
...src/anoncreds/services/IndySdkAnonCredsRegistry.ts	61.37% <88.23%> (ø)
... and 8 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[genaris]

Super! Really liked the import function in DidsApi.

[genaris]

If a key is already in the wallet, Wallet object is supposed to make us know about it by throwing an Error. The problem is: what's the resulting wallet state if only some of the provided keys are already present? If we got an error when calling this method because of this, we cannot tell afterwards which ones were actually saved, so it could be confusing.

It could be also confusing the fact that probably we set the overwrite flag and we could expect not only the DidRecord to be overwritten if already existing (because we are an average developer that does not read the JSDoc 😛 ).

I think it will be safer to check all provided keys for presence before doing anything that can modify wallet state. But of course this could be part of another PR, once we update Wallet API appropiately.

[TimoGlastra]

Good points. Let me see how easy it is to check if a key exists. I think I'll have to do some updates to the indy-sdk-react-native for this. Oh well 🤷

[TimoGlastra]

Ok, so there's no way to check if a key exists in indy-sdk. You can get metadata, but this will only return something if there's actual metadta for that key.

It does throw WalletItemAlreadyExists error, which we could check if a key already exists by actually thying to create it. But yeah, then you would have the key in the wallet.

So what I'm going to pursue now (please mention if you have a better approach), is the following: loop through all private keys and call createKey. If an error is thrown that the key already exists we just continue as the intended outcome is the same: all private keys are in the wallet.

[genaris]

Agree, I think that's the best we can do for the time being. Would be nice to quickly explain in a comment or add a TODO to remember about it and improve when indy-sdk finally go to a better life ;-).

[TimoGlastra]

Something wrong the CI.... Looking into it

[TimoGlastra]

Would really like to get this one merged today... 👀

[genaris]

Would really like to get this one merged today... 👀

CI is on fire today. We'll make it!