Record successful ERC725 attestations in DB

[franckc]

For some context, see #46

1. For our initial V1 launch we need to decide if we want to record in the bridge server DB successful ERC725 attestations including personal identifier such as email, phone, social networks handles, etc...
2. For longer-term @joshfraser mentioned the idea of storing the root of a merkle tree onchain so people can prove their data has been verified by us without their actual data being stored onchain or on our servers. Would be good to flesh out the details of how this would actually work.

@joshfraser Could you provide some input on 1. in particular ? And additional details/thoughts on 2. if you have any.

[joshfraser]

We have a strong preference against storing any personally identifiable information but recognize that it may be important for us to see the raw data to prevent abuse if we're issuing rewards based on completing attestations.

For context, we've been investigating the idea of offering token rewards for signing up or referring friends to the platform (much like most sharing economy platforms offer new user & referral incentives today). Growth is one of the most important things for any network, and something we'd like to incentivize. Unless we come up with a good answer for how to prevent Sybil attacks, these rewards will likely have to be granted from a centralized system instead of programmatically from a smart contract. The problem is if all we can see is the root of a merkle tree, there will be no way to spot even obvious abuse (like creating attestations for josh+1@email.com, josh+2@email.com, etc for the rewards).

Merkle trees allow users to hold their own data & we can publish a proof that we verified their data without storing the data itself. I haven't dug into the implementation details of this, but at a high level, it sounds like the best approach.

[tomlinton]

One idea might be to provide token rewards only for attestations that are hard to perform Sybil attacks on, e.g. Airbnb users with x reviews. If we set up some minimum criteria for attestations to get rewards and initially manage it with a centralized database we can be reasonably sure that the system isn't being abused when everything ends up as a leaf node in a merkle tree later on.

[franckc]

Yes, good idea regarding limiting sybil attacks by only granting reward token to identities that can demonstrate some level of activity (airbnb reviews, facebook posts, tweets).

[franckc]

Regarding ability to publish a proof that Origin verified a given identity claim. As opposed to implementing a merkle tree proof approach on the Origin side, I'm wondering about the possibility to leverage events that are emitted and recorded on the blockchain as part of the ERC 725 flow. In particular the "ClaimAdded" event. The event has a "data" argument. What if in that data we would include the encrypted (using the user's wallet address) email address, twitter handle, airbnb ID, etc... that was verified as part of the claim. Couldn't that serve as a proof ? Given her email address and her waller public address, a user could prove Origin verified her identity claim. Also those events have indices which should allow anyone to quickly retrieve them when needing to get a proof. I'm not deeply familiar with ERC 725, so perhaps @nick you could comment on whether this makes any sense or not :)

[nick]

I think that makes sense... though we may want to salt the data as it'd otherwise be trivial to, for example, try AirBnb ID 1-10000000 and brute force it.

For example, the data attribute could be keccak256(email, salt). When the user wants to prove their email was verified by Origin to a 3rd party, they supply their email and the salt. The 3rd party can then verify the data in the claim matches keccak256(email, salt) and that it was signed by Origin.

Of course, this means the user storing their random salt somewhere. Perhaps it could be some derivative of their Eth private key, for example the sha of the first 16 bytes? Ideally it would be totally random, but then it'd need to be stored somewhere.

[franckc]

Yes, agreed data should be salted. My crypto fu is weak, but using part of the private key to generate a salt makes sense to me as well.

[franckc]

Adding @tyleryasaka since he is deep diving into ERC 725.

[joshfraser]

We want to store attestations again before mainnet so we can see how people are using the DApp.

[tomlinton]

Done by #137. :tada: