Roadmap
The goal is a complete, isolated, fully functional TrustPlane Auth runtime that stays provider-neutral, locally verifiable, and useful without mandatory hosted services. Published release artifacts are available now. This page summarizes product direction; use Current and future scope for the canonical support matrix and exact artifact availability.
Current foundation
Section titled “Current foundation”The current foundation is local proof-bound request verification: passports, transcript-v1,
replay consume-on-accept, route/source policy, signed bundles, a brownfield adapter, a local
broker, deployment packaging, conformance vectors, and caller-side SDKs for Go, Node.js-only
TypeScript, and Python.
Near-term direction
Section titled “Near-term direction”- Improve gateway and middleware ergonomics around protected request verification.
- Harden deployment and chart workflows around signed local bundles and digest-pinned images.
- Expand conformance and example coverage for integrations that need stable request-signing behavior.
- Design MCP, n8n, and workflow integration packages after API stabilization.
Later direction
Section titled “Later direction”- Kubernetes-native configuration surfaces such as CRDs.
- Envoy and OPA integration examples.
- Broader deployment examples and optional cloud integration test harnesses.
- Additional SDKs and workflow packages after the core wire contract stays stable.
What stays out (by design)
Section titled “What stays out (by design)”TrustPlane Auth will not become a service mesh, a CA replacement, an OAuth replacement, a payment network, or a marketplace. Managed governance — persistent principals, approvals, hosted bundle distribution, revocation feeds, RBAC, compliance, and tenant isolation — is out of scope for this runtime. TrustPlane Auth stays the local, provider-neutral verifier.