Exposing/configuring identity and configuring trust from a guest?

[jeffparsons]

Excited to see this!

I couldn't find anything here about exposing/configuring identity (e.g. key pair for self, public key for peer) or configuring trust (trusted peer public keys).

Is this stuff purposefully out-of-scope — e.g. because there are reasons you intend this to be up to the embedder — or just not considered/specced yet?

Thanks! 💖

[badeend]

you intend this to be up to the embedder — or just not considered/specced yet?

A combination of both.

The current interface is extremely MVP, with emphasis on the Minimal part. The very first experimental implemementation landed just 2 days ago so don't be surprised to see that the current interface is missing basically everything. 😄

WASI sits in a potentially interesting space here; because embedders have the ability to configure TLS settings on a per-component-instance basis. This means that we may get away with not exposing the bulk of (possibly dangerous) APIs that traditionally had to be exposed to the application. For example: even though the WASI interface has no APIs to configure TLS versions or cipher suites, the host is still free to offer these configurations using hypothetical CLI arguments:

wasmtime run my-component.wasm --min-tls-version=1.2 --disallow-cipher-suite=md5

To answer your question:

Is this stuff purposefully out-of-scope

I don't consider anything out-of-scope just yet. The current strategy is to start with a high-level API and "leave it up to the host" wherever possible, and revisit specific scenarios based on feedback from real-world implementation efforts such as dotnet/runtime#109569. To prevent ending up in a situation like this. 🙃

[badeend]

Was your question out of curiosity or do you have an immediate need for this? If not, I'll close this as resolved.

[jeffparsons]

No immediate need, and my only current use cases are hobby projects using QUIC. The vast majority of my other use cases are served well by wasi-http.

Thanks!