Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Protocol Specs] More Flexible Plugin Permissions #65

Open
nlordell opened this issue Nov 8, 2023 · 0 comments
Open

[Protocol Specs] More Flexible Plugin Permissions #65

nlordell opened this issue Nov 8, 2023 · 0 comments

Comments

@nlordell
Copy link
Collaborator

nlordell commented Nov 8, 2023

Currently, permissions are tied to a plugin (i.e. a plugin reports its required permissions) and not tied to an enabled plugin (i.e. account enables plugins with some permissions). I think that this distinction is important to make as a plugin may partially work with reduced permissions, so "required permissions" should just be the minimum permissions required for the plugin to work, and not all the permissions that a plugin can make use of.

As an example use case:

Let's say that you want a ERC-4337 plugin. User 1 wants to allow the EntryPoint to execute transactions on behalf of the account, but does not want to allow the EntryPoint to modify account settings (so no CALL_TO_SELF or EXECUTE_DELEGATECALL permissions). User 2 wants to use the same plugin, but is OK with giving the Entrypoint full control over the account, so it would enable all permissions.

In that use-case, you would have to deploy at least 2 different plugins with different permission bits set in order to support both users. One solution would be to potentially not include the requiredPermissions as part of the plugin itself but rather have the permissions set when the plugin is enabled. The details of which permissions are required and which are optional can also be included in metadata and doesn't need to be completely "machine readable".

Not necessarily suggesting that something should change, just documenting a potentially not covered use-case that may be worth considering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant