This is a great proposal!
This should allow for so much nicer user interface.
I have been thinking along these lines for quite some time and I ll here shamlessly plug my related proposals as I think they bring a different perspective that might be helpful to be aware of:
There is 3 proposals in there. The two on signature are similar to appkey in intent but use the main account (no isolation) and is restricted to EIP712 signature in its current form. it allows them to be used without modification, except for an extra domain Seperator field in EIP712.
The one on encryption could be applied to app keys.
In that article, it is also mentioned the idea of smart contract domain approval by users. This would allow users to stay in control of which domain has the right to act on behalf of the users on each smart contract following the standard. For app keys I guess this can be done via address. Any plan to standardise such in this proposal?
This one (modified in this direction by @pedrouid) could also be used for app keys to let wallet.appkey.enable return an authenticated account by passing a challenge to the request, instead of having the application to do a signature request on top.
As for general comments, I ll have a closer read later, but few things jumped to mind :
the option to use app keys per content hash is I think very important for fully decentralised app where even the app creator and ENS name owner should be considered malicious. Relying on the ENS is prone to vulnerability as you mentioned. ENS should be used for discoverability not as the basis for security. As such app key should ideally be using the contentHash for the domain, when such is used.
Having said that I think it could also be an option to have app keys for ENS names to allow application to update without having to scare their users with another enable popup or share data with earlier version easily. This should be clearly indicated to the user though as a warning when accepting such ENS name based app keys.
Similarly: App keys should work with DNS names. I am not sure I understand the rational behind refusing them. Is it really not possible to come with a normalization scheme similar to ENS ?
Looking forward to play with such proposal!