Workload Identifier Origin Hint for TLS ClientHello#

Yaroslav Rosomakho, Jonathan Hoyland (individual, TLS WG)

• Why: mTLS works well for workloads but there's no easy way to enable it on a shared endpoint — today you typically need a separate TLS server endpoint just to issue CertificateRequests. This extension lets a workload client signal mTLS capability and identity namespace in the ClientHello.
• What: A TLS ClientHello extension carrying a list of workload identifier origins (URI scheme + trust domain, e.g., the spiffe:// scheme and trust-domain part of a SPIFFE ID). Presence of the extension tells the server the client (a) won't break on a CertificateRequest and (b) can present a certificate for one of the listed origins; the server uses the hint to decide whether client authentication is required and which policies/trust anchors apply.
• How: An optional origin list in the extension; an empty list degenerates into a pure "request mTLS" flag. For privacy, the list can be carried in the Inner ClientHello under ECH with an empty outer list, hiding identifier information from on-path observers.
• Where applicable: Machine-to-machine TLS deployments — SPIFFE/WIMSE-style workload identity, proxies, OT/IoT — not user-facing browsers. Early individual draft (-01) gauging TLS WG interest; complements SPIFFE client auth (OAuth layer) and the WIMSE effort.