Skip to content

FAQ

Quick answers to the questions that come up most when teams evaluate or operate TrustPlane Auth. Each answer links to the page that covers the mechanism in depth.

What is the difference between TrustPlane Auth and TrustPlane Control?

Section titled “What is the difference between TrustPlane Auth and TrustPlane Control?”

They are the two planes of the TrustPlane platform: Auth is the enforcement plane (it verifies each machine request locally at the boundary) and Control is the governance plane (the cockpit for enrollment, policy releases, revocation, fleet visibility, audit, and operator access). They are distinct components designed to be used together — Control governs the same bundles, keys, and policies Auth enforces — but Control is never a hot-path dependency: Auth verifies locally, and traffic keeps flowing even if Control is unreachable. See Control.

Auth is free to use — run it from the published artifacts with no account or hosted service. Control is the enterprise offering, delivered as managed SaaS. TrustPlane Edge is the self-hosted deployment of Control, with advanced, tailored capabilities for organizations that need the governance plane inside their own environment.

Is this a replacement for OAuth / API keys / a service mesh?

Section titled “Is this a replacement for OAuth / API keys / a service mesh?”

No. TrustPlane Auth is not an OAuth replacement, not a CA replacement, and not a service mesh. It adds request-bound, short-lived, proof-bound authorization on top of whatever workload identity you already have (SPIFFE, OIDC/JWT, or a local issuer).

No. TrustPlane Auth is Kubernetes-compatible, not Kubernetes-required. It runs as local processes, on VMs, at the edge, on EC2/Droplets, and in CI. SPIFFE/SPIRE is the recommended production identity integration for Kubernetes, but it is optional.

No. TrustPlane Auth works locally and offline with no account, database, or hosted bundle source. You build trust material and policy bundles by hand (or with trustplane bundle build / merge-source) and mount them. Managed lifecycle for those artifacts is out of scope for this runtime; the runtime never depends on a hosted service. At fleet scale, that managed lifecycle is what TrustPlane Control provides — always outside the request path.

What stops a stolen passport from being replayed?

Section titled “What stops a stolen passport from being replayed?”

Four things compound: short expiry, audience/route scoping, transcript-v1 request binding (so it only works for the exact request), and atomic replay consume (so the jti is one-time). See the security model.

What does attested_workload actually guarantee?

Section titled “What does attested_workload actually guarantee?”

That the broker verified a workload’s X.509-SVID before issuing the passport. It does not mean the broker’s signing key is hardware/enclave/KMS-backed or non-exportable, and the verifier does not re-verify the SVID per request — it trusts the broker issuer key from the bundle.

Can I add a new client without redeploying?

Section titled “Can I add a new client without redeploying?”

Yes — that’s a headline feature. Use trustplane bundle merge-source to append the client’s public key + a route source rule, then publish/mount the bundle (locally, or via the bundle refresh workflow). The adapter image and Deployment do not change. See Brownfield APIs.

Yes, for local bundles. Use trustplane bundle remove-source with --confirm-remove to remove a trusted key and matching route source selector while preserving unrelated trust material and policy. Add --revoke when the reviewed output should append local revocation metadata for that removed key/source. Revocation across a fleet is TrustPlane Control’s job as the governance plane; hosted revocation feeds are not currently supported in this release.

Why are policy checks ordered before replay?

Section titled “Why are policy checks ordered before replay?”

So a malformed or unauthorized request is rejected without consuming the caller’s one-time jti. Otherwise an attacker could “burn” a victim’s passport by spraying junk. Replay state is consumed only on an otherwise-valid presentation.

What’s the difference between trust material and a policy bundle?

Section titled “What’s the difference between trust material and a policy bundle?”

Trust material = the trusted public keys (by kid). Policy bundle (trustplane-bundle-v1) = per-route rules: allowed_sources, required_key_binding, and freshness_class. The verifier needs both.

trustplane bundle build emits an unsigned skeleton until the reviewed output is signed with trustplane bundle sign. Production-style adapter loading should require bundle-signing public keys and reject unsigned or tampered trust/policy material unless an explicit local dev flag is selected.

Run make v01-acceptance — the deterministic, local acceptance gate. See the acceptance gate.

trustplane-auth builds the adapter and broker artifacts from source. The adapter is published as an immutable, digest-pinned GHCR image by the runtime release process; a broker container image is not part of the current release (the broker runs from source builds and the local demo). Deployment packaging references runtime artifacts; it does not rebuild runtime code.

Which languages can sign proofs the Go verifier accepts?

Section titled “Which languages can sign proofs the Go verifier accepts?”

Any language that implements transcript-v1 identically. TrustPlane Auth includes Go, JavaScript, and Python conformance harnesses (make transcript-conformance) precisely to guarantee byte-identical transcripts across languages.

These docs track the TrustPlane Auth runtime and deployment artifacts. If a command, field, or reason code here drifts from released behavior, treat that as a documentation bug to fix in the same review as the product change.