Multichain Permission Adapter -> Maintain wallet_getPermissions
backwards compatibility
#4239
Labels
barad-dur
enhancement
New feature or request
PermissionController
Related to the PermissionController.
team-wallet-api-platform
When successful,
wallet_getPermissions
andwallet_requestPermissions
both return the current permissions for the requesting subject, which is a subset of the permission controller's state. This is very unfortunate, because it means that we are externalizing the state of an otherwise internal module, and makes changes to its state breaking changes of our public API. In preparation for the introduction of a multichain API and its new permissions (see #4241), we should introduce an adapter function between the permission controller at the RPC methods that return its state.This adapter function should take the permission controller state and return a public representation thereof, perhaps modeled on what we already do for Snaps manifest permissions. We can then ship this public state representation as part of our API, and do whatever we want with our internal state. This public representation should focus on what's strictly necessary for the consumer to understand the authority they've been granted, and nothing more. In particular, it should not contain any ZCAP-LD properties or make mention of caveats, all of which we should regard as implementation details.
Complication:
window.ethereum
Of course, we have already shipped our current internal state via
window.ethereum
(and potentially the Snaps provider). The adapter must be written such that, for interfaces that supportwallet_getPermissions
andwallet_requestPermissions
they return the same state that they do today, unmodified. If necessary, they can support newly introduced permissions as well, but we cannot break this APIs for existing consumers, and especially consumers ofwindow.ethereum
.The text was updated successfully, but these errors were encountered: