At MetaMask, we have begun to experiment internally with a variation of this app keys proposal. Its implementation is a bit simpler:
const appKeyPrivKey = ethUtil.keccak(privKey + originString, 256)
This could be exposed as an RPC method to allow any domain to request its own app key associated with the current requested account (if available):
const appKey = await provider.send({
method: 'wallet_getAppKeyForAccount',
params: [address1]
});
An important thing to define here will be how we generate originString, since this needs to be completely unique to the requesting domain.
We may be able to simply include the protocol prefix domain separator like : to separate a unique type string from the main domain identifier. For example, a few valid origin strings might be:
https://ethereum-magicians.org
ens://danfinlay.eth
eth://0x5A0b54D5dc17e0AadC383d2db43B0a0D3E029c4c
ipfs://QmVhFMu7ryuFyRXm8gpxWmVuSsLR5H9Z91j8YcTrc9GmUL
This allows each page to have its own per-account deterministic seed.
While this does not explicit cover cases of sharing these app keys between pages on its own, I believe that need can be met by composition:
Since a domain would get a unique key, and because domains can intercommunicate, one domain (app) could request another domain (signer) to perform its cryptographic operation on some data, with its appKey as a seed, potentially allowing new signing strategies to be added as easily as new websites.
This could also pass it to domains that are loading specific signing strategies. This may sound dangerous at first, but if a domain represents a static hash of a trusted cryptographic function implementation, it could be as safe as calling any audited internal dependency.
Anyways, posting it here because we’re experimenting with this variant, and I wanted to get it out there in case anyone else is about to implement the parent EIP, which I may revise or submit an alternative to soon.