pm-idm

pm-idm copied to clipboard

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.

@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.

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

it is yes :)

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.

@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.

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.

@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?

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

@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.

@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.

@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.

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.

@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?

@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.

@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.

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.

@satazor What about this issue?