Workload Identifier Origin Hint for TLS ClientHello#

Yaroslav Rosomakho, Jonathan Hoyland.

• Why: mTLS between workloads has an awkward bootstrap: a client can't know which cert/trust domain a server will accept, and servers can't enumerate acceptable trust domains — so deployments burn separate TLS endpoints. This fixes that with a small wire-format change.
• What: A TLS ClientHello extension carrying one or more workload identifier origins (URI scheme + trust domain, drawn from the WIMSE identifier format). Presence of the extension signals the client won't choke on a CertificateRequest and can produce a certificate for a listed scope; the server uses the hint to decide whether client auth is required and which trust anchors apply.
• How: An empty list is valid and degenerates into a "request mTLS" flag; for privacy, combine with ECH — empty list in the Outer ClientHello, real scopes in the Inner.
• Where applicable: Cross-organization workload mTLS (the motivating case: a server with trust relationships with thousands of customer trust domains). Individual draft -02, with the authors asking whether there's appetite for an adoption call — this is the piece that makes WIMSE credentials usable in the TLS handshake.