BrightID request for funding

[adamstallard]

Request for Nest membership and funding ( #60 )

Team name: BrightID

Proof of concept / research whitepaper: whitepaper | web-site | github

Burn rate: $11k per milestone for nine two-week milestones. (1 full-time and 4 part-time contributors). (Approx. $22k per month).

Legal structure: Campaign in Aragon or Giveth DAC

• Team
• Roadmap

Proposal

Finish the creation of BrightID mobile, which allows users to create their anonymous BrightID and receive a trust score through private connections with trusted contacts.

We will also create the first anti-sybil systems to analyze the trust graph.

Aragon is starting work on a simple identity app (Aragon-ID). We will integrate a sybil-resistant anonymous identity solution (BrightID) into the Aragon-ID app. It will allow a user to show their likelihood of being a real, unique person (i.e. a BrightID trust score), without revealing any identifying information.

In addition, BrightID trust score lookups by Ethereum address will be available to any Aragon apps through a smart contract function call.

Aragon-BrightID Integration.

UI Components for Aragon-ID

Identity profile view (design prototype: https://github.com/aragon/design/issues/5). We assume there will also be the ability to view another user’s profile.

From an identity profile, if the profile owner has a BrightID, there will be a BrightID badge showing the user’s trust score expressed as a percentage. The badge also shows a date when the trust score was last updated.

Hint text explains BrightID and trust scores.

If the identity profile belongs to the current user and there is no BrightID associated with their Ethereum address, there will be a button and invitation to “Link your BrightID.”

If clicked, a modal dialog shows an area to enter an access token and a link to app stores for those who aren’t yet users.

UI Components for BrightID (mobile app)

A series of screens allow a user to upload an ethereum address by scanning a QR code.

The final screen displays the access token needed for Aragon.

Underlying functionality

Creating a mapping between BrightID and Ethereum

A BrightID public key will be mapped to an Ethereum address.

1. From the BrightID app, a user selects “Link Ethereum Address.” The user enters an Ethereum address.
   1. This creates the message <BrightID Pub Key><Ethereum Address><Timestamp> and signs it with the user’s BrightID private key.
   2. This first part of the request is sent to a BrightID node, which generates and returns an access token. The access token is displayed to the user and copied to their clipboard for use in the following step.
2. From the Aragon-ID app, a user selects “Link your BrightID”. The user enters the access token from the previous step.
   1. The following message is signed by metamask <Access Token><Ethereum Address>Aragon<Timestamp>and sent to a BrightID node.
3. The BrightID node checks that the messages are signed correctly and match the supplied parameters, and that the BrightID isn’t already mapped to an Ethereum address in the DApp context (Aragon). If this succeeds, it creates a mapping between the Ethereum address and the BrightID public key.

   Uploading or updating a user’s trust score to the smart contract

   After a mapping between between a BrightID and an Ethereum address is established, anyone can call a smart contract function to request an updated trust score for an address.

This is done automatically the first time a mapping is made.

1. A call is made to a BrightID node to request that a trust score be updated. In the request, the client specifies an Ethereum address. The client gets back a signed request (signed by the node) of the format <Ethereum Address>Aragon trust <Trust Score><Timestamp>.
2. The client sends the signed request to the smart contract which verifies that the request was signed by a private key belonging to an allowed node, and then adds or updates the score to the contract, indexed by the Ethereum address and the DApp context (Aragon).
3. This is done without user interaction except a possible confirmation in metamask.

   Checking a trust score

   BrightID trust score lookups by Ethereum address and DApp Context are available through a smart contract function call. BrightID users can have only one Ethereum address per DApp context.

---

Please see the roadmap for a complete list of what will be accomplished with this grant.

We're looking forward to a decentralized future with Aragon and BrightID!

[CLAassistant]

All committers have signed the CLA.

[adamstallard]

Here's a doc describing of the Aragon-BrightID integration piece in greater detail.

[adamstallard]

I had another talk with @abramsymons and cleaned up the Aragon-BrightID Integration more.

[adamstallard]

@abramsymons had the idea to have our own (BrightID hosted) web3-enabled web page to handle all the integration functions, the URL for which would by displayed by the BrightID mobile app.

Account linking and score updating would be done from that page, and then the only integration point on the Aragon-ID app would be to display BrightID scores on the ID profile pages for those users that have one.

What do you think @sohkai @jounih , and others?

[abramsymons]

@adamstallard is absolutely right. Please note that this design prevents Bright-ID and Aragon-ID from getting too tightly coupled. It would not be a proper approach to have Aragon ID UI modified every time Bright-ID makes changes to its smart contract, server side codes, or their architecture.

[adamstallard]

@abramsymons At a minimum, they'll have to use our smart contract to read in brightid trust scores linked to ethereum addresses.

If linking an ethereum address and requesting a score update is only done from our own page, then we don't have to worry about other applications--such as Aragon--needing to use them, and it would be easier to make a breaking change to the parameters if we had to for some reason.

[adamstallard]

The CLA Assistant is having issues. It seems to have forgotten all our signatures, and I don't seem to be able to sign it again.

[mariapao]

@Smokyish can you help us with the CLA issues?

@adamstallard we haven't forgotten about this proposal. This application is very interesting to us. We are not as responsive as usual because part of the team is on vacations.

[adamstallard]

@mariapao Thanks for the response. I'm very glad to know you're still interested.

[Smokyish]

Hi @adamstallard and @mariapao.

Because this Pull Request has multiple commits from multiple contributors, all three need to sign the CLA.

So @adamstallard is okay, but @abramsymons and @RnbWd also need to sign the CLA before the PR can successfully be merged.

[adamstallard]

@Smokyish I will ask them to sign it again. It removed all three of our signatures a week ago for no discernable reason.

[Smokyish]

@adamstallard Yes, there was an update on the CLA that caused it to require re-signing for committers that had PR's that weren't merged. Looks all good now. cc @mariapao

[adamstallard]

Added some images to the pull request and google doc.

[sohkai]

@adamstallard Sorry for the delays! Really love how this is shaping up :). @jounih may have a few things to say about the design but the technical aspects of this integration are really interesting, and I totally agree that decoupling BrightID from any particular dapp is the right choice (I see it as a "provider" of trust that anyone can look up).

One thing that's not totally clear for me is how an ID profile would pull information; would it just be one contract call like BrightID.getScoreFor(<user>, <app>)? The flow for updating someone's trust score also worries me–is the end user who sends the updated score to the chain or is the trust model just a signature verification that a trusted BrightID node has sent me updated information (I think I'm really confused here 😅)?

I probably just don't have enough context / working assumptions to understand that last bit, but otherwise, I'm a huge fan of this and really looking forward to the integration!

[adamstallard]

@sohkai

I totally agree that decoupling BrightID from any particular dapp is the right choice (I see it as a "provider" of trust that anyone can look up).

Same. The modal dialog that shows "connect with BrightID" is our code hosted by us to provide the utility for linking BrightID public keys to ethereum addresses. It could be displayed in a frame.

One thing that's not totally clear for me is how an ID profile would pull information; would it just be one contract call like BrightID.getScoreFor(<user>, <app>)?

Yes, that's exactly right--the <user> is an ethereum address, and the Dapp context is "Aragon."

The next question--which I'll attempt to answer below--is "how do trust scores get into the smart contract in the first place?"

The flow for updating someone's trust score also worries me–is the end user who sends the updated score to the chain or is the trust model just a signature verification that a trusted BrightID node has sent me updated information (I think I'm really confused here sweat_smile)?

Yes. Let's say I want to update my own trust score or upload it for the first time.

BrightID nodes have a mapping of public keys to ethereum addresses. They also have a mapping of public keys to trust scores.

First, I send a request to a BrightID node to get a trust score for my ethereum address signed by the node's private key.

The message has the format:

<Ethereum Address>Aragon trust <Trust Score><Timestamp>

Each instance of the smart contract has a whitelist of allowed BrightID node public keys.

Then the smart contract is called to submit this signed message. The smart contract checks to see that the public key used to decrypt the message is in its whitelist. If so, then it's safe to associate the trust score (and timestamp) to the ethereum address.

All of this is done with no interaction from the user, except possibly to approve the gas cost to submit the message to the smart contract. It's done for the first time as the final step of the linking process.

[mariapao]

Hi @adamstallard 3 questions/comments:

1. Just to confirm, the timeline of the project is more or less 4 months, right? with a burn rate of $22k per month.

2. The BrightID mobile app is not going to be an Aragon app but it will be integrated within the Aragon Identity app?

3. Given our push for mainnet we likely won't be building out the identity app before late October, I imagine this will affect your timeline?

[adamstallard]

Hi @mariapao

1. Yes.
2. Yes, and the smart contract we create (trust score lookup by ethereum address) is available to any other smart contracts within Aragon--not just the Aragon ID app.
3. We can demo Milestone 8 whenever you're ready. The integration piece is about 20% of the total work of this grant. We can split the grant into two parts, 80/20 and hold off collecting the last 20% until the Aragon ID app is also ready.

How does that sound to you?

[mariapao]

That sounds great! @adamstallard We think the smart contract for accessing trust scores could be built as an aragon app, to have some more governance over it (e.g. only allow new nodes to be "whitelisted" through a vote), and this should be fairly trivial.

[adamstallard]

Sounds perfect @mariapao .

And as far as the timeline, 16 weeks from now is Dec 8th. If the Aragon team will be working on Aragon-ID in late October and November, maybe we can still demo the final milestone with the UI integration on schedule in December, but if we need to push it back to Jan, that shouldn't be a problem--we can split the funding.

[mariapao]

Hi @adamstallard ok. Great. We just wanted to make this clear to set expectations :)

One last question, how are you guys approaching the validation of the accuracy of the system?

[adamstallard]

Hi @mariapao

One last question, how are you guys approaching the validation of the accuracy of the system?

This is a very important question, and the heart of what we're doing. The "trust score" has to accurately mean "likelihood of being a unique person in the system at hand."

We're modeling different anti-sybil systems, different parameters to those systems, and different sybil attack scenarios. Two of the milestones (week 4 and week 10) end with demos of our modeling efforts to show how accurate trust scores can be in the face of known attacks.

This is an ongoing effort that doesn't end with the 16 week roadmap. After the beta is launched in week 14, we will have real user data coming in that we can incorporate into our models. The key is to understand what attacks are possible, to model them, and to make adjustments to the systems and parameters.

Competing and complimentary anti-sybil systems are encouraged--each node is free to use a different system, and applications are free to incorporate multiple results when retrieving trust scores. Part of the ongoing mission of BrightID is to provide continuing anti-sybil research to improve the accuracy of trust scores.

Other supporting components of the BrightID mission include providing a very high-quality list of "seed groups" to use as input to anti-sybil systems; and a framework for bounties as an incentive to discover vulnerabilities.

[sohkai]

🎉 really looking forward to seeing the demos that come out of this @adamstallard!

[joeycharlesworth]

Hey @adamstallard , just wanted to check in here to see if you guys are still working on this BrightID project with Aragon? Did you manage to complete the project in the end?

[adamstallard]

Hey @adamstallard , just wanted to check in here to see if you guys are still working on this BrightID project with Aragon? Did you manage to complete the project in the end?

Yes. But the ninth milestone wasn't funded or completed. Here are the milestones. Aragon was having financial difficulties at the time.