# Problems with DID:ETHR

## Table of contents

1. diverging smart contract versions
2. smart contract development/deployment life cycle
3. smart contract data migration
4. replay attack vulnerability on the default contract

### 1. diverging smart contract versions

Veramo tried to publish the version `1.0.0` of the DID ethr smart contract. They then put the address to it in the DID spec. Later they found out that they accidentally deployed an old version of the contract. This results in some bugs in the current default smart contract dictated by the spec.

### 2. smart contract development/upgrade life cycle

At the moment Veramo is the only developer investing efforts in changing the smart contract. Currently there is no established system for upgradeability of this as the spec points to a hardcoded address that has no proxy capabilities. So we're kind of locked in the usage of the current version until somebody deploys a new version & somehow succeeds in changing the spec.

### 3. smart contract data migration

If you want to upgrade the smart contract & don't support data migration you'd lose old DID data. Upgrading the contract should always somehow migrate the old data. Currently it's kind of a black box whether that even works with the approach the contract takes for data storage (using events).

### 4. replay attack vulnerability on the default contract

The old version of the contract (default one right now) has an active attack vector that enables people to replay meta transactions for DID document changes on the following methods:

* addDelegateSigned
* revokeDelegateSigned

This could enable attackers to do the following in a constructed situation:

1. trading partner on CARO wants to add a delegate (superCool Inc.) to their DID document
2. signs a meta transaction body with the respective parameters
3. trading partner gives it to CARO payment wallet
4. CARO payment wallet signs & submits the meta transaction on Ethereum (anchors the signed meta transaction body in the public blockchain)
5. the blockchain is updated
6. <some time passes and the DID document changed over time due to usage of the ATP>
7. an attacker signs & submits the public information of the old meta transaction of step 4. again
8. superCool Inc. is again a valid delegate inside the trading partner DID

## Proposal

Before we deploy ethr DIDs to production we need to push the ecosystem to use the new version of the smart contract. As its address on the blockchain will be hardcoded in the did:ethr spec we need to have a stable address from that point on forward. We need a way to proxy the contract to enable hidden upgrades in the contract. As this is a critical method in the whole DID standard (because some entity is able to change the behaviour of did:ethr -> could result in changing the appearance of someone's DID) we need to have a governance model in place that the community trusts. It should be some kind of DAO.

So we should do the following:

1. We engage ourself in the process of owning the did:ethr contract (owning means: fixing bugs, developing solutions, taking care of governance)
2. We build a governance solution for the did:ethr contract
3. We think of how to migrate the data in the smart contract and enable the smart contract to be upgraded
4. We push the community to use a new stable fixed version of the did:ethr contract

## Random links that may be of interest

* [Merge Request that acted as a rabbit hole for this](https://github.com/decentralized-identity/ethr-did-resolver/pull/164)
* [Link to old contract, currently in use](https://github.com/uport-project/ethr-did-registry/blob/f8d80ffd3e71bc96e8cc19d38822dcc8f7682b99/contracts/EthereumDIDRegistry.sol)
* [Link to did:ethr spec](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md)