mTLS
Also called mutual TLS, mutual Transport Layer Security, client-certificate authentication
mTLS, mutual TLS, is regular TLS, the encryption standard behind every
https:// connection, with an extra verification step switched on. In
ordinary (one-way) TLS, only the server proves who it is: your browser
checks the server's certificate before trusting the connection, but the
server just takes whatever request arrives. mTLS adds the missing half,
the client also presents its own certificate, and the server checks it
before accepting the connection. The practical effect: two services can
authenticate each other cryptographically before exchanging a single byte
of application data, without either side ever sending the other a password
or an API key that could leak in a log file.
This matters most for service-to-service traffic inside a system with many moving parts, microservices, background workers, autonomous agents calling each other's APIs, where "did I actually hear from the service I think I did?" is a real question a shared secret answers weakly (secrets get copied into logs, leaked in config files, and don't prove which holder of the secret is actually calling) and a certificate-based handshake answers much more strongly.
Where it comes from
Client-certificate authentication is not new; it's been part of the TLS/SSL certificate exchange since the 1990s and is standardized today under the IETF TLS working group (TLS 1.3 is RFC 8446). What changed is adoption: mTLS became a default expectation for internal service traffic through the CNCF service-mesh ecosystem, Istio, Linkerd, and the Envoy proxy all ship automatic, mesh-wide mTLS as a headline feature, and through Google's own internal zero-trust network architecture (BeyondCorp, and its internal ALTS transport). None of it is Solidus's design.
Solidus status
Solidus's own architecture documentation names mTLS as a security target
for inter-service traffic, but naming a target isn't the same as shipping
it, and it hasn't shipped. Concretely: the design plan for verify's private
GPU inference server states its own auth mechanism today as a shared static
bearer token over one-way TLS, with mTLS explicitly deferred to "a future
v3." The compute network's broker (see Verifiable Off-Chain
Compute) authenticates node traffic
the same way, a BROKER_AUTH_TOKEN bearer secret, not a client
certificate. That's a real, not cosmetic, gap: a bearer token that leaks can
be replayed by anyone who has it; a client certificate that leaks still
requires the matching private key to be usable. No Solidus service, as of
this writing, authenticates a peer via mTLS.
Proof: none, there's nothing to demonstrate, because Solidus hasn't
built this. The honest, checkable adjacent fact: the compute broker's
bearer-token check, and its own boot-time warning when the token is unset,
is visible in source in the gpu-node/apps/broker package of the
private monorepo.
Where it comes from
Someone else specified this. Solidus assembles it.
mTLS is ordinary TLS, the encryption protocol behind every HTTPS connection, with one extra step turned on: the client also presents a certificate, so the server can cryptographically verify who's calling it, not just encrypt the traffic. Client-certificate authentication has been part of the TLS/SSL family since the 1990s, standardized today under the IETF TLS working group (TLS 1.3 is RFC 8446). It was popularized for service-to-service traffic specifically by the CNCF service-mesh ecosystem, Istio, Linkerd, and Envoy all make mTLS-by-default between microservices a core selling point, and by Google's own internal zero-trust infrastructure work (BeyondCorp, ALTS). Solidus did not design TLS, mTLS, or any service mesh; it composes the standard where it uses it at all.
How to check this
Solidus has not built this. The entry explains the concept.
None, there's nothing to demonstrate, because Solidus hasn't built this. The honest, checkable adjacent fact: the compute broker's bearer-token auth check is visible in source in the gpu-node/apps/broker package of the private monorepo, and its own boot-time warning documents the gap when the token is unset.