Repository navigation
Add "Endowment" permissions - #152
Conversation
7ea42f4 to
a5cc8f0
Compare
84c7392 to
1e35fe9
Compare
| @@ -126,7 +143,8 @@ const permissionSpecifications = { | |||
|
|
|||
| // This is a namespaced restricted method. | |||
| wallet_getSecret_*: { | |||
There was a problem hiding this comment.
wallet_getSecret_* => 'wallet_getSecret_*'
| }, | ||
|
|
||
| // This is an endowment. | ||
| secretEndowment: { |
There was a problem hiding this comment.
Should it be possible for the endowment to be unrestricted? That would mean that all endowments ever used would be specified in one place only - in PermissionController.
There was a problem hiding this comment.
Yeah, at the time of writing, I can't think of any unrestricted endowment that would have to be specified. In the context of SES, for instance, an unrestricted endowment would just be available by default.
| // Getting endowments internally is the only option, since the host has to apply | ||
| // them in some way external to the permission system. |
There was a problem hiding this comment.
Nit: I found this comment a little confusing. I assume that "getting endowments internally" means getting them from within our codebase rather than via RPC method. It makes sense to me that endowments are internal, because... well... we only have a JSON-RPC API, and that doesn't include endowments as a concept (at least not directly).
But I don't know what "the host has to apply them in some way external to the permission system" means, or what its relevance is to whether endowments are exposed via RPC or not.
| * caveat specifications available to the controller. | ||
| */ | ||
| export type PermissionControllerOptions< | ||
| ControllerPermissionSpecification extends ValidPermissionSpecification<PermissionSpecificationConstraint>, |
There was a problem hiding this comment.
Why was ValidPermissionSpecification removed here? Not disagreeing, just the reason wasn't clear to me.
There was a problem hiding this comment.
Ah, ValidPermissionSpecification<PermissionSpecificationConstraint> evaluates to never with the new types when used as the right-hand operand of an extends expression. The other uses of ValidPermissionSpecification still work, and it didn't really add anything here, so removing it seemed like best move.
4 participants
Introduces the notion of permission types to the
PermissionController, and adds "Endowment" permissions. Invoking these permissions required a new method and action,PermissionController.getEndowmentsandPermissionController:getEndowments, respectively. See the updatedPermissionControllerREADME and linked issue for details.Here is the description of endowment permissions, from said README:
The name "endowment" comes from the endowments that you may provide to a Secure EcmaScript (SES)
Compartmentwhen it is constructed.SES endowments are simply names that appear in the compartment's global scope.
In the context of the
PermissionController, endowments are simply "things" that subjects should not be able to access by default.They could be the names of endowments that are to be made available to a particular SES
Compartment, but they could also be any JavaScript value, and it is the host's responsibility to make sense of them.At present, endowment permissions may not have any caveats, but caveat support may be added in the future.
Closes #137