EIP1775 - App Keys: application specific wallet accounts, in Status

Browser
1

This is an old idea Status always wanted to have, that Status could have one account per dapp and that this accounts would be derivable.

Recently an EIP for this was submitted, and from my review it seems exactly what Status was considering - and more, as multiple personas. So under the same Dapp user can select a specific persona - which will always be the same for that seed phrase.

Therefore I want to start the discussion on implementing this on status-react.

  1. Is this good enough for what Status wants ?
  2. How Status should implement personas, i.e., UX of personas ?
  3. How to protect privacy between personas or dapps?
  4. How this affects keycard and other external keystore devices?

EIP1775 - App Keys: application specific wallet accounts

https://eips.ethereum.org/EIPS/eip-1775
Allow users to derive wallets specific to dapps and personas.
In Status.im: important for multiaccount as privacy, security or utility feature.

EIP1775 and Privacy

Privacy feature requires a funds mixer to be actually effective, so the creation of “virtual personas” for different dapps and funding them through mixers - therefore the source of funds cannot be traced and each identity can’t be associate one to other.

image

Ethereum ZK-SNARKs based funds mixer:

The wallet could support a feature for privately funding wallets by using existent mixers (not developed by Status), but an audit on the foreign system should be done before giving this option to users.

EIP1775 and EIP1102 (Opt-in account exposure)

EIP1102 should disclosure the DApp account, or the common account, depending on user selection.
It should not matter much for EIP1102, however it should consider what account is selected, and if none was selected, it should prompt for user selection.
It might be cases where user authorized multiple keys for the same dapp session (it might have an use-case for this?)

EIP1775 in top of EIP1581 (Non-wallet usage of keys derived from BIP-32 trees)

EIP1775 could be derived inside of EIP1581, meaning of a “non wallet usage dapp specifc key”. This is something we might want to “enhance” on EIP1775.

Impact on external keystore

For signing transactions users will need to unlock the keystore just like any other wallet key.

For deriving a new Dapp-specific key, users would have to unlock they keystore, in the case of keycard, use the NFC. There is a way we could derive it without unlocking keystore (for display only)?

History of discussions

@gravityblast and @jarradhope already started simillar discussions: