search

burnsignal / burnSignal-Spec

This repo is the specification for the Burner Vote application
3 stars 2 forks source link

Ethereum Address Mapping (to BrightID) Service (web app) #1

Closed adamstallard closed 4 years ago

adamstallard commented 4 years ago

Needs to allow someone to navigate to it on their mobile device.

If they go there on their desktop, use web3 to figure out what ethereum address they want to use, then generate a QR code that they can scan on their mobile device that takes them to a page in their mobile browser where the ethereum address is already populated and they just need to click a button to open BrightID (through the deep link).

Or allow them to paste an ethereum address. That will also create the deep link (that needs to be clicked.)

adamstallard commented 4 years ago

Not sure of the design, but it could just be a giant button that says link to my BrightID.

auryn-macmillan commented 4 years ago

@adamstallard can me map multiple ethereum addresses to one brightID account?

adamstallard commented 4 years ago

No, only one at a time. If an application allows you to switch--which I think this one should--then there is a permanent record of your past addresses.

auryn-macmillan commented 4 years ago

Is there some reason not to allow users to associate more than one ethereum address?

Is there functionally any difference between allowing users to associate more than one address and keeping a permanent record of all past addresses? What if an app just used that list of addresses to as a reference to all of the addresses that belong to this user? The only undesired effect I can think of is in the case that a user's private key is compromised, in which case they would have no way to deactivate it from their list of accounts.

adamstallard commented 4 years ago

Is there some reason not to allow users to associate more than one ethereum address?

Is there functionally any difference between allowing users to associate more than one address and keeping a permanent record of all past addresses? What if an app just used that list of addresses to as a reference to all of the addresses that belong to this user? The only undesired effect I can think of is in the case that a user's private key is compromised, in which case they would have no way to deactivate it from their list of accounts.

Yeah, you're right. We call the list "revocableIds" but I agree we should just publish the list of "revocableIds" and let the apps that use service decide what to do with them. A few options:

  1. Treat all IDs (ethereum addresses) as coming from the same person and allow them to be used interchangeably.
  2. Enforce one account (ethereum address) per person; i.e. only use the latest one and revoke the other ones from logging in to their app.
  3. Disallow changing ethereum addresses at all. This is what dollar for everyone does, since it's a one-time process of getting your dollar.
auryn-macmillan commented 4 years ago

Treat all IDs (ethereum addresses) as coming from the same person and allow them to be used interchangeably.

I really like the sound of this option, but I feel like you would need an option to disable old addresses in case one was compromised or you otherwise lost control of it. So addresses in the list would need something like an isCurrent bool.

Tomasvrba commented 4 years ago

Agreed with also being able to revoke/remove old addresses. Could be a lost/compromised address, or simply just wanting to delete one for privacy reasons.

adamstallard commented 4 years ago

I agree, too. The current implementation was created with one id (address) at a time in mind. To support what we have in mind would require new functionality to allow a user to selectively revoke a past id (right now it always revokes, i.e. forces one id at a time).

auryn-macmillan commented 4 years ago

Or allow them to paste an ethereum address. That will also create the deep link (that needs to be clicked.)

Users should probably have to prove that they control the account, no? In which case, pasting in an address is probably not a good solution.

adamstallard commented 4 years ago

Or allow them to paste an ethereum address. That will also create the deep link (that needs to be clicked.)

Users should probably have to prove that they control the account, no? In which case, pasting in an address is probably not a good solution.

Giving your verification to some address you don't control isn't much of an attack. It only prevents you from assigning it to an address you really do control.

The system we've set up prevents you from revoking a verification from an address someone else is using, but it doesn't bother to stop you from linking it to any address.

Doing it this way makes it simpler by not requiring you to authenticate with the other application (in this case signing with your ethereum key) at the time you make the link.

Here's the process implemented in the current BrightID version as described in the new whitepaper.

auryn-macmillan commented 4 years ago

So multiple BrightIDs could be linked to one ethereum address?

adamstallard commented 4 years ago

So multiple BrightIDs could be linked to one ethereum address?

Yes.

Tomasvrba commented 4 years ago

Closing this issue, as the MVP version of this is functional. I will open additional issues to address specific things that still need to be done.