FAQ
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).
Do I need Kubernetes?
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.
Do I need any hosted service to use it?
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.
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 Security model.
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?
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 Add a client, no redeploy.
Can I remove or revoke a client?
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. Managed hosted revocation remains future Control work.
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?
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.
Is the bundle signed?
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.
How do I know the runtime is healthy?
Run make v01-acceptance — the deterministic, local acceptance gate. See
The acceptance gate.
Where do the adapter and broker images come from?
trustplane-auth builds the adapter and broker artifacts. Published images should be immutable,
digest-pinned, and produced by the runtime release process. Deployment packaging should reference
runtime artifacts; it should not rebuild runtime code.
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.
Where do I report that a doc is wrong?
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.