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

Add "incremental" permission revocation and caveat "subtraction" #4236

Open
rekmarks opened this issue May 1, 2024 · 0 comments
Open

Add "incremental" permission revocation and caveat "subtraction" #4236

rekmarks opened this issue May 1, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request PermissionController Related to the PermissionController.

Comments

@rekmarks
Copy link
Member

rekmarks commented May 1, 2024

Following the closure of #4163 (#4222), we will have introduced a notion of "caveat merging" and incremental permission requests to the permission controller. Call this "additive permission requests". To complete the picture, we of course need to add the inverse operation, i.e. "subtractive permission requests" or "incremental revocation". (Really, "incremental" is not an ideal word for this—"partial", anyone?—but since we have already designated "revoke" as the inverse of "request"... here we are.)

Here's a sketch of how this will work:

  • The caller specifies caveat values for a set of permissions that they would like to revoke.
  • The permission controller only attempts to delete these caveat values, nothing else.
  • Each caveat specification will include a new property, tentatively named subtractor, where consumers have to specify how incremental revocation will work for their caveat.
    • We can potentially reuse the CaveatMutatorOperation conceit for this.
  • If the caveat is "emptied" by this operation, it is deleted.
    • It'll probably be the subtractor's responsibility to determine if a caveat is empty, but TBD.
  • If validation fails after revocation, the request rejects.
  • If a permission is specified without naming any caveats, the whole permission will be revoked.
    • Maybe we'll do something more explicit like { wallet_foo: '*' } to signal that the whole thing should go, but TBD.
@rekmarks rekmarks added enhancement New feature or request PermissionController Related to the PermissionController. labels May 1, 2024
@rekmarks rekmarks self-assigned this May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request PermissionController Related to the PermissionController.
Projects
None yet
Development

No branches or pull requests

1 participant