Namespaced permissions were introduced as part of the original PermissionController (rpc-cap) because we thought it would be a good way to parameterize certain permissions. For example, you could do something like wallet_deriveKey_* where * is a BIP-44 derivation path. We did all of this and more at various points during Snaps development.
Eventually, we realized that anything expressible as a namespaced permission is also expressible as a caveat. Furthermore, caveats are no more difficult to make intelligible to the user in the UI than a namespaced permission.
Ultimately, by having both namespaced permissions and caveats in our permission system, we have two different ways of parameterizing / attenuating permissions, to no obvious benefit. While everything expressible as a namespaced permission is expressible as a caveat, the reverse is not true (see e.g. eth_accounts). For this reason, we should remove namespaced permissions from the PermissionController.
Namespaced permissions were introduced as part of the original
PermissionController(rpc-cap) because we thought it would be a good way to parameterize certain permissions. For example, you could do something likewallet_deriveKey_*where*is a BIP-44 derivation path. We did all of this and more at various points during Snaps development.Eventually, we realized that anything expressible as a namespaced permission is also expressible as a caveat. Furthermore, caveats are no more difficult to make intelligible to the user in the UI than a namespaced permission.
Ultimately, by having both namespaced permissions and caveats in our permission system, we have two different ways of parameterizing / attenuating permissions, to no obvious benefit. While everything expressible as a namespaced permission is expressible as a caveat, the reverse is not true (see e.g.
eth_accounts). For this reason, we should remove namespaced permissions from thePermissionController.