This is meant to be a place to discuss the blog post: Account Coordinator: A Proposal for the Future of Wallets.
2 Likes
One thing I didn’t quite capture with the final diagram illustrating the coordinator is that it’s intended to abstract over multiple key managers, which is one of the largest UX pain points right now. While Metamask lets you handle multiple keys, if you want to use Metamask + a mobile wallet for different applications you end up with a proliferating number of wallets and it gets very hard to keep track of which keys are where, associated with which dApp, and in which context. The Account Coordinator solves precisely this problem.
2 Likes
Something I started thinking through with @pedrouid and @ethanfrey was the details of the user experience after each data transport step took place. So you start on the application, it uses walletconnect to attach to the account coordinator. This is essentially what we see today. The account coordinator receives the transaction from the application, shows it to the user and suggests which key manager to use. At this point there will need to be another walletconnect data transport to the key manager. On a ledger, you’d expect to see the transaction info one more time to confirm before signing. At this point the user would be viewing the tx data twice which feels redundant.
I’d wanted to know if there was a hash, uid, or emoji style message that could be used in place so that a user just needs to confirm it’s the same message on both sides rather than review the entire transaction. Pedro pointed out that doing so would mean the security assumption of the key manager must now include the account coordinator. One goal of separating the two is that the account coordinator can be compromised without compromising the keys. If the key manager just relied on a hash, uid or emoji message coming from the account coordinator, and the account coordinator is compromised, the keys follow suit.
If there were an easier way for a human to server essentially the same purpose as a hash function this may be improved. For example the attack scenario would mean that the account coordinator could show a message that looks correct, but actually send a malicious message to the key manager for signing. The coordinator would show a hash that it claims came from the correct message, but actually came from the malicious one. Confirming that on the signing side would feel like confirming the correct message, because a human can’t tell when a hash actually represents the input data. If there were some way to easily confirm a hash from a third party then it might be possible to rely on the hash. unfortunately this ends up just pushing the problem further down the line where compromise is still possible.
Another topic I’d like to think through further is with regard to MetaMask’s snap system and if and how exactly it might improve the relationship between the account coordinator and the key manager. In that scenario, the account coordinator would ask for specific permissions to access different keys from the key manager. Does that mean that if the account coordinator is compromised the permissions it has on the various keys also become compromised?
If so maybe you actually wouldn’t want that kind of access from the AC?