Take a look at the possibility of using wit-bindgen with the policy engine.
The motivation for this is that this would hopefully allow for interoperability with other host languages, like Python, JavaScript, Rust, and Go. Rust is there on purpose, as even though the Policy Engine is written in Rust others might like to be able to integrate it in a safe way using wasm for isolation.
One potential use of this could be in-toto which have a suggestion regarding allowing writing rules in various policy languages and this would allow embedding wasm components as a sort of plugin (I think).
[x] Learn about wit-bindgen. Notes and examples can be found here
[x] Investigate how/if the policy engine can be compiled to wasm and used with wit-bindgen. Notes and examples can be found here.
[x] Update the engine.wit to work with recursive types.
Follow up tasks (suggestions)
Recursive types
The WebAssembly Component model currently does not support recursive types which there a quite a few in the policy engine. It sounds like the plan they have is to leave support for this out of the Minimal Viable Product (MVP). We could perhaps express our "concern" about this and see if they would reconsider this.
Go support for WebAssembly Component Model
I've not been able to find a Go wasm runtime that supports the component model yet. There is wasmtime-go but it does not support the component model yet, but there is an issue for it. Perhaps we could try to add this support if Go support is critical.
There are other Go libraries which might be interesting to look closer at, like wazero
Java support for WebAssembly Component Model
Similar to Go I've not been able to find a Java wasm runtime that supports the component model yet. For Java there is wasmtime-java.
Reqwest issue
I've written about this issue in the notes linked above. After that I learned about reqwest-wasi which could perhaps be used when we target wasm32-wasi.
Take a look at the possibility of using wit-bindgen with the policy engine.
The motivation for this is that this would hopefully allow for interoperability with other host languages, like Python, JavaScript, Rust, and Go. Rust is there on purpose, as even though the Policy Engine is written in Rust others might like to be able to integrate it in a safe way using wasm for isolation.
One potential use of this could be in-toto which have a suggestion regarding allowing writing rules in various policy languages and this would allow embedding wasm components as a sort of plugin (I think).
Follow up tasks (suggestions)
Recursive types
The WebAssembly Component model currently does not support recursive types which there a quite a few in the policy engine. It sounds like the plan they have is to leave support for this out of the Minimal Viable Product (MVP). We could perhaps express our "concern" about this and see if they would reconsider this.
Go support for WebAssembly Component Model
I've not been able to find a Go wasm runtime that supports the component model yet. There is wasmtime-go but it does not support the component model yet, but there is an issue for it. Perhaps we could try to add this support if Go support is critical.
There are other Go libraries which might be interesting to look closer at, like wazero
Java support for WebAssembly Component Model
Similar to Go I've not been able to find a Java wasm runtime that supports the component model yet. For Java there is wasmtime-java.
Reqwest issue
I've written about this issue in the notes linked above. After that I learned about reqwest-wasi which could perhaps be used when we target
wasm32-wasi.work in progress...