Tree based wallet permissions

[mpeterdev]

Thinking about #9 and transaction support, we may be able to cut off the concern that some child component down the page may present a user with a wallet action which is either malicious or outside the scope of what the root dapp intended. All non-root components could need to be granted permission—either explicitly or automatically— for the type of transactions they wish to execute, and any requests to present the user with a transaction outside that scope would be ignored.

There are some different options on strictness. Considering the following component tree

Component C is a modal which the root dapp intends to present a user with a transaction to sign. A few approaches:

Auto-propagating permissions

The root dapp gives subtree rooted at Component A permission to use wallet APIs. When attempting to call one from C we crawl the tree upwards until we find a non-root component with the right permissions, or ignore if we find none before the root component. In order to deny permission for Component D, we would need to add a negative flag for Component B to explicitly not pass the permission to D and any of its children.

Manually propagating permissions

Every component must explicitly state if any permissions are to be passed to a subcomponent. The root dapp would give Component A permission, Component A would give Component B permissions, and Component B would give Component C permission. Components E and D have no permissions by default. This is the most robust model, but also the most cumbersome.

Auto-propagating deny permissions

All components have all permissions by default, a subtree can be denied permission if there is no intent to have it leverage wallet APIs. I hesitate to use the word "sandbox" here since it could be confused with other facets of BWE, but it's somewhat accurate. The root component would use a prop like walletApisAllowed: false for Component E. Component B could do the same for Component D. When attempting to call a wallet API, we would crawl the tree upwards. If we encounter a component which has been denied the appropriate permissions before the root, we would ignore the call

@andy-haynes

[andy-haynes]

Is Root dapp component in the diagram another BOS Component or is it the outer application rendering BWE? My understanding is that all signing would be happening in the outer application which renders the Component tree, so I had envisioned that the permissions model would be part of the interface between the outer application and the Component tree. I'm wary that driving this from the root Component at render time via props adds complexity by requiring the outer application to track which Component trees have which permissions.

To me this is a good candidate for static, permission-based configuration when initializing BWE. In this model all permissions would be opt-in, requiring the outer application to specify the Component (or Component subtree, or whatever arbitrary criteria) permitted to carry out the specified permission.

So instead of something like:

// outer application
const { components } = useWebEngine("RootDappComponent");

// RootDappComponent
<Component src="ComponentA" hasTransactionSigning={true} />
<Component src="ComponentE" />

// ComponentA
<Component src="ComponentC" />

// ComponentC
...
<button onClick={() => requestSignTransaction() />
...

You'd specify the permission upfront:

// outer application
const { components } = useWebEngine("RootDappComponent", {
  permissions: {
    "transaction.sign": [
      "ComponentA*", // enable for all descendants of A
      /*
        other potential options:
        "ComponentC", // enable only for C
        (txSignRequest) => { ... }, // enable only for requests satisfying a predicate
        "*", // enable for all
      */
    ],
  },
});

// RootDappComponent
<Component src="ComponentA" />
<Component src="ComponentE" />

A big tradeoff here is needing to specify the Component permissions statically. This would be more explicit, making it easier for the outer application to reason about which Components have access, but comes at the cost of inflexibility (e.g. no way to specify a partial subtree that excludes some Components).

[mpeterdev]

We're talking about different security layers. The goal for my proposition is to enable BOS developers to add constraints to their BOS dapp and lower the risks of composability. A BOS dapp is just a component which is meant to be loaded directly via a gateway (outer application) as opposed to embedded within other components. These developers would have no access to modifying the outer application— they would only ever touch component code, so their constraints would need to be specified either inside the component code or in component metadata.

[mpeterdev]

although I suppose if the permissions are specified in component metadata, it could be part of the outer application's responsibility to fetch that and use it during the useWebEngine initialization as you've shown above.

I agree that driving permissions via props adds significant complexity. I think it will likely be worth it in the long run but we should back that with user research