Open
Description
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.
- We can potentially reuse the
- 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.
- Maybe we'll do something more explicit like