Feature request: implement localJWKS documented in JWT verification design

[nissy-dev]

Summary

The JWT verification design document describes localJWKS on spec.virtualhost.jwtProviders as a supported way to configure JWT providers (as an alternative to remoteJWKS, with exactly one of the two required).

That localJWKS behavior is not implemented yet in Contour. This issue is a feature request to implement localJWKS as specified in the design.

Why this matters

localJWKS is the right model when JWKS should not be fetched over the network at runtime.

• Restricted egress / air-gapped clusters — no reliable path to an external https://…/jwks.json (or policy forbids it), but issuers still use asymmetric keys you control and can publish as JWKS once.
• Static or slowly rotating keys — small platforms, internal APIs, or gateways in front of a single IdP where key material is stable; a local JWKS avoids an extra moving part (remote endpoint availability, DNS, TLS to the JWKS host).
• Operational and security posture — keep signing keys and JWKS only in-cluster (e.g. Kubernetes Secrets), with no dependency on JWKS URL uptime, redirects, or certificate changes on a third-party host.
• Simpler GitOps / config-as-data — JWKS bundled with the same revisioned manifests as the HTTPProxy (depending on final API shape), instead of coordinating a separate always-on JWKS HTTP service.

Without localJWKS, these deployments are pushed toward remoteJWKS or workarounds even when a local key set is sufficient and preferable.

References

• Design: design/jwt-verification-design.md (localJWKS alongside remoteJWKS)
• Related JWT work: #4723
• Prior user report (unknown field / expectations around localJWKS): #6658