The http proxy integration supports multiple authentication types, but none of them do quite what I want:
Http basic, bearer, and custom header all require the recipient to keep a secret, which is inconvenient to secure when the recipient is a VM that has a coding agent in it.
Peer-to-peer doesn't require keeping any secrets, but it doesn't identify the sending VM, and only works for VM-to-VM connections.
They all have their uses, but as an alternative, how about if a VM had a built-in way to sign an arbitrary request? The request could contain the id of the sending VM, the VM's tags, a timestamp, and a payload, and it could be signed by a private key maintained by the exe.dev infrastructure. (I'll omit the details because I'm not a security expert.)
This could be another http proxy authentication option, or more flexibly, it could be a separate service that's transport-independent. Perhaps a shell command?
In #181 I proposed a simpler alternative that doesn't use cryptography. An advantage of signing with a private key is that it would be useful for authenticating requests for both a VM-to-VM connection and from a VM to an outside recipient. (For example, a server running on my laptop.)
There are existing standards for such a thing, like RFC 9421 (http message signatures) and RFC 7515 (JSON signatures). I don't know what's best.
The http proxy integration supports multiple authentication types, but none of them do quite what I want:
Http basic, bearer, and custom header all require the recipient to keep a secret, which is inconvenient to secure when the recipient is a VM that has a coding agent in it.
Peer-to-peer doesn't require keeping any secrets, but it doesn't identify the sending VM, and only works for VM-to-VM connections.
They all have their uses, but as an alternative, how about if a VM had a built-in way to sign an arbitrary request? The request could contain the id of the sending VM, the VM's tags, a timestamp, and a payload, and it could be signed by a private key maintained by the exe.dev infrastructure. (I'll omit the details because I'm not a security expert.)
This could be another http proxy authentication option, or more flexibly, it could be a separate service that's transport-independent. Perhaps a shell command?
In #181 I proposed a simpler alternative that doesn't use cryptography. An advantage of signing with a private key is that it would be useful for authenticating requests for both a VM-to-VM connection and from a VM to an outside recipient. (For example, a server running on my laptop.)
There are existing standards for such a thing, like RFC 9421 (http message signatures) and RFC 7515 (JSON signatures). I don't know what's best.