Thanks for drawing my attention here, @jpitts! Hadn’t seen this one yet.
A couple of my answers to the questions by @vbuterin that are not addressed in the linked EIP:
How would that work for multi-contract dapps?
Our current EIP assigns a unique domain string to whatever app it connects to, this should be the most secure string we can attribute to the loading site, so public key, site hash, or ideally ENS address is presented as our preferred initial solution.
This allows many keys to be assigned in many ways, and all that is needed to allow multiple domains to then seamlessly integrate is a delegation system for these app keys, which can/will be part of a later proposal.
Ideally from a UX point of view, it would still feel like the user makes one operation; the UX of dapps that requires users to sign three transactions in a row to do something honestly really sucks.
I totally agree. We are definitely building towards making the initial sign-in increasingly look like a coherent contract that sets terms that allow the app to accomplish the user’s goal with minimal subsequent approvals, while enforcing hard restrictions under the hood based on those terms.