# 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