Consider adding a secrets interface to the `wasi:config/imports` World

[Mossaka]

Secrets management is considered different from configuration management due to the nature of the sensitivity of the secret value. I propose we consider adding an additional interface dedicated for secrets management in this proposal.

Design Goal: the handle of secrets should be opaque to the guest, revealing no secret data that can be directly accessible by the applications.

Possible interface:

/// secret is a WIT resource. The secret value is kept opaque to prevent
/// accidental exposure. Operations that require the secret can be performed via methods on this resource.
resource secret {
    /// signs the data using the secret to perform cryptographic operations.
    sign: func(
        data: list<u8>
    ) -> result<list<u8>, error>;
}

Discussion: I also realized how limited the proposed secret resource is, given that there are many more use cases that are not just about signing data, like a connection string to an external database. So what should be an appropriate scope for the secrets management in wasi:config?

[thomastaylor312]

So actually we already have one spec'd out for this: https://github.com/wasmCloud/wasmCloud/blob/main/wit/secrets/wit/secrets.wit.

We started this in wasmCloud because we wanted to prove it out and come with an implementation so we knew it could work. This wit works because a component may have access to a secret but not have permission to reveal it. The secret resource can then be passed around to something else that may actually reveal it

Signing should never be part of secrets IMO because a secret is a secret. It could be a key, token, or string (or anything else). So something that wanted to sign could either import the secrets interface directly and fetch it or it could be something like this:

interface data-signer {
    sign: func(s: secret, data: list<u8>) -> result<list<u8>, error>;
}

[thomastaylor312]

My current thinking is that we should get the current config interface moved to phase 3 and then add in the secrets interface. We can then add in the secrets stuff as a separate interface under wasi:config with @unstable and vote on/work on that separately