Support ethr DID method in the JS IDM Wallet

[satazor]

Description

Support ethr DID method in the JS IDM Wallet.

For now, the idm-wallet module just supports the IPID did method. Though, we should add at least one more to prove its concept. I would suggest adding ethr, which is the latest DID method used by uport.

To do this, we just need to add ethr.js and change didm/index.js to forward all ethr did methods to its correspondent functions.

Acceptance Criteria

• [ ] Implement ethr.js which uses https://github.com/uport-project/ethr-did
• [ ] The ethr.js should have the exact same interface as the existent ipid.js file
• [ ] The key generation from the mnemonic should be the same that uPort uses, which is bip32. I think we can use the already existent human-crypto-keys, but needs to be tested.

[satazor]

@vasa-develop

• The interface of all methods in ethr.js should be exactly the same as ipid.js, meaning that the adapter layer will be a little bit more complicated.

  As an example: the operations parameter of both create() and update() is a function that is called to mutate the document, and is being used by the identities scope, see: https://github.com/ipfs-shipyard/js-idm-wallet/blob/ce90f54ea1b97c9af2e1a9f6760d53daf1e59e43/src/identities/index.js#L110. The operations function (as well as many others) is not yet documented in the spec, but you may find documentation here: https://github.com/ipfs-shipyard/js-did-ipid#operations. In that adapter layer, you would need to map any functions calls to the document parameter (of the operation function) to the setAttribute of ethr-did.

• The params parameter is a bag of parameters specific to each DID Method. As an example, similarly to the ipid did method, the ethr-did expects a privateKey which we must reconstruct from a mnemonic. This mnemonic should be passed in the params.

• Ideally, the provider, network and other configuration options for ethr-did should be configurable as well. This could be done via a configuration/options parameter in the constructor/factory of ethr.js. Then, we could allow users to set the configuration/options in the createIdmWallet options, for each DID method, e.g.:

createIdmWallet({
  didMethods: { ipid: { /* ipid options */ }, ethr: { /* ethr options */ } }
})

We may start simple and allow this in a separate issue.

• Consider lazy loading ethr.js with dynamic import so that it doesn't weight much in the bundle size.

We can do this in a separate issue, we just need to create the issue so that we won't forget.

[satazor]

@oed hello! Quick question: is the ethr the most recent did method used by uport?

[oed]

it is yes :)

[vasa-develop]

UPDATE: ok. Finally, I have all the components for did-ethr working. They really do have crappy docs and the incompatible web3 provider makes it even worse.

[vasa-develop]

@satazor

In that adapter layer, you would need to map any functions calls to the document parameter (of the operation function) to the setAttribute of ethr-did.

Here, is the file https://github.com/ipfs-shipyard/js-idm-wallet/blob/ce90f54ea1b97c9af2e1a9f6760d53daf1e59e43/src/identities/index.js the adapter layer? I am asking this for figuring out where should I add the code for mapping the setAttribute function.

[satazor]

The adapter layer is the didm scope, see https://github.com/ipfs-shipyard/js-idm-wallet/blob/master/src/didm/index.js. You need to integrate ethr-did in didm/methods/ethr.js, mapping document function calls to setAttribute and friends.

[vasa-develop]

@satazor For now, I am using ethereum specific libs to regenerate the keyPair or private key from the param. But going forward, I think we should add the support for it with the human-crypto-keys package.

Does that sound ok to you?

[vasa-develop]

@satazor Why we don't add the createDidIpid method in the constructor itself?

[satazor]

@satazor For now, I am using ethereum specific libs to regenerate the keyPair or private key from the param. But going forward, I think we should add the support for it with the human-crypto-keys package.

Does that sound ok to you?

Yep. What is it missing in human-crypto-keys to support key pair generation for ethr?

@satazor Why we don't add the createDidIpid method in the constructor itself?

Unfortunately we can’t because it’s async, and constructors in JS can’t be async.

Actually it’s not async. You can move it to the constructor if you want to.

[vasa-develop]

@satazor

Yep. What is it missing in human-crypto-keys to support key pair generation for ethr?

I need to have secp256k1 algo support for key generation. Plus, I need to have the key exported in hex format. So, also support for that.

P.S. Do I have write permission for this repo? I am not able to push to a new branch in this repo. Or should I clone it in my account and go forward.

[vasa-develop]

@satazor There seems to be no definition of a device key in the ethr-did specification.

So, how do we add a device key? Any thoughts?

There are definitions for delegate keys which can act as signing keys.

[vasa-develop]

Are there any weekly/bi-weekly calls for IDM? If yes, then please add me to the list. It will be better to discuss these issues over a call so that we can discuss probable problems and their solutions.

[vasa-develop]

@satazor The identity folder makes heavy use of orbitDB for its working. Should I have to create method-specific identity folders, that can be imported in the identities index.js, and managed from there?

[satazor]

@vasa-develop Yes we have bi-weekly progress calls, but we are figuring out the roadmap for the next quarters. They are in standby for now and we hope to resume them very soon.

[satazor]

@vasa-develop in terms of replication provider per identity. This would be really hard to do, since each DID-method is doing it's own thing. Later on, having a data provider per identity makes sense but it's a beast that needs to be tamed at his own time.

[vasa-develop]

Later on, having a data provider per identity makes sense but it's a beast that needs to be tamed at his own time.

Seems like it deserves a separate issue.

[vasa-develop]

@satazor What about this issue?