---
# System prepended metadata

title: Brainstorm for capability inheritance

---

# Discussion of capability inheritance for component dependencies

In the proposal for adding [component dependencies](https://www.notion.so/fermyon/Early-Draft-of-Component-Dependencies-SIP-314b246d340b4d469ddff58ee924947e?pm=c) there is an open question about how to handle capability enforcement. The options being:

1. By default (with no explicit toggle) dependencies inherit all capabilities from the dependent component, e.g:
```toml
[component."infra-dashboard"]
# ...
allowed_outbound_hosts = ["https://google.com"]

[component."infra-dashboard".dependencies]
"aws:client" = "0.1.0"
```
In this scenario, when the `aws:client` is composed with the `infra-dashboard` the `aws:client` component will inherit access to the `allowed_outbound_hosts` granted to the `infra-dashboard` component.

This is the ultimate punt on answering this question and unfortunately seems like the riskiest option. It would be very counter-precedent to implicitly opt users into a behavior that seems like an anti-pattern of a capability based system. However, as a counter-point, this is effectively how things work today when using tooling such as `wac plug` and is the simplest deliverable for the season.

2. Via explicit toggle to enable opting in-or-out of capability inheritance, e.g.:
```toml
[component."infra-dashboard"]
# ...
allowed_outbound_hosts = ["https://google.com"]
depedencies_inherit_capabilities = true | false

[component."infra-dashboard".dependencies]
"aws:client" = { version = "0.1.0" }
```

If `inherit_capabilities` is `true`, dependencies of the `infra-dashboard` component will inherit access to its capabilities. This is similar to the first option but captures the explicit intentnion to enable that behavior.

If `inherit_capabilities` is `false`, there are two behaviors we can support:
* We error informing the user that disabling capability inheritance is not yet supported. 
* We invest time into building a virtual-adapter that disallows access to various capabilities. This would essentially be an initial version of `spin-virt` that disallows all. I anticipate this to be a non-trivial investigation..

The big question here is what should the default behavior of this option be in the scenario that `inherit_capabilities` is omitted while dependencies are provided. I'm of the opinion that the default should be `false`, however that entails applying the disallowing virtual adapter mentioned previously. 


3 Versions:
1. Disallowing adapter (inherit_capabilities = false) via `spin-virt` (stubbing out everything that is opt-in via wasi + spin).
2. Granular toggling of specific capability inheritance (e.g. http, environment, etc...) -- If we need something more before Wasi 0.3.
3. Full hog