Cryptographic enhancement: Sign hash of description of granted permissions

[danfinlay]

If a permission's description is changed, those previous permissions should be invalidated, because it may imply that the previous permission was worded deceptively and consent was maybe given illegitimately.

Additionally, permissions objects are easy to forge for anyone who has disk access.

If we incorporated a signature of granted permissions into the grant flow (and maybe app keys for delegations), and we validated those signatures during permission traversal, we would gain a few benefits:

• Capabilities would be much harder to spoof, even with disk access (as MetaMask never stores private keys to disk)
• The wording of a permission would be bound with the consent given, and so analysis of why a person granted permission could always include analysis of the exact terms they consented to.

[rekmarks]

In the new implementation of rpc-cap, permissions no longer contain any descriptions, as that responsibility is delegated to the host (which can then internationalize the descriptions as appropriate). Although there are still many enhancements to make, this particular issue no longer applies.