Context
Follow-up to #1338 / #1340.
The current client_cert_resolver field accepts Arc<dyn ResolvesClientCert>, which is a rustls trait re-exported from the crate root. This works but has drawbacks:
- Semver coupling — a rustls breaking change becomes a Temporal SDK breaking change
- Ergonomics — users must understand
CertifiedKey, SignatureScheme, and has_certs() to implement the trait
- Asymmetry — the Go SDK's
GetClientCertificate just returns (cert, key, error)
Proposal
Add an SDK-owned trait alongside the raw re-export:
pub trait ClientCertProvider: Send + Sync + 'static {
fn get_client_certificate(&self) -> Option<(Vec<u8>, Vec<u8>)>; // (cert_pem, key_pem)
}
Internally, build a ResolvesClientCert adapter. This covers the 90% use case (file-watching, Vault) trivially, while the raw trait remains available for power users (HSM-backed signers).
References
- Go SDK:
tls.Config.GetClientCertificate
- Review discussion: 4 reviewers independently recommended this
Context
Follow-up to #1338 / #1340.
The current
client_cert_resolverfield acceptsArc<dyn ResolvesClientCert>, which is a rustls trait re-exported from the crate root. This works but has drawbacks:CertifiedKey,SignatureScheme, andhas_certs()to implement the traitGetClientCertificatejust returns(cert, key, error)Proposal
Add an SDK-owned trait alongside the raw re-export:
Internally, build a
ResolvesClientCertadapter. This covers the 90% use case (file-watching, Vault) trivially, while the raw trait remains available for power users (HSM-backed signers).References
tls.Config.GetClientCertificate