Glossary
The terms you meet in the TrustPlane Auth CLI, contracts, bundles, and audit logs, defined the way the rest of the docs use them. Each entry is short; follow the links from other pages for the full mechanism.
Acceptance gate
Section titled “Acceptance gate”The deterministic, local readiness check for the TrustPlane Auth runtime, run with
make v01-acceptance. A green gate exercises the full local broker, adapter, and bundle pipeline
and confirms the documented allow and deny outcomes; it does not authorize release tags,
publishing, or cluster deployment.
Adapter
Section titled “Adapter”The trustplane-adapter reverse-proxy verifier that sits in front of an API and enforces
passports, transcript-v1 proof, route policy, and replay protection before a request reaches
the upstream. On allowed requests it adds X-TrustPlane-* headers; missing passports get 401
and wrong-audience presentations get 403. See also brownfield adapter.
allowed_sources
Section titled “allowed_sources”The per-route list of source rules a route accepts. Each entry names an issuer, trust domain, subject (exact or prefix), and required key binding, so a single route can authorize multiple distinct sources instead of one global trust domain.
Attested workload
Section titled “Attested workload”The strongest signer class, attested_workload. It means the broker verified a caller’s
SPIFFE/SPIRE X.509-SVID before issuing the passport. It does not mean the broker’s signing key is
hardware/enclave/KMS-backed, and the verifier does not re-verify the SVID per request — it trusts
the broker issuer key from the bundle.
Audience
Section titled “Audience”The aud passport claim naming the specific API or service the passport is for. A passport
presented to the wrong audience is denied, which limits how far a stolen passport can travel.
Audit event
Section titled “Audit event”A stable JSON record (trustplane-auth-audit-event-v0.1) describing each allow or deny decision,
including reason_code, route_id, and transcript_sha256. Emitted by broker, verifier, and
adapter decisions.
Broker
Section titled “Broker”A small local service, reached over a Unix domain socket, that issues request-bound passports to
callers. By default it signs with a local software Ed25519 key; on Kubernetes it can verify a
caller’s SPIFFE/SPIRE X.509-SVID before issuing an attested_workload passport.
Brownfield adapter
Section titled “Brownfield adapter”The adapter deployed in front of an existing, unmodified upstream API so the API gains proof-bound authorization with no application change and no image rebuild — the “wedge” pattern for existing services.
Bundle policy
Section titled “Bundle policy”The route-level rules carried in a trustplane-bundle-v1 policy bundle: per-route
allowed_sources, required_key_binding, and freshness_class. A verifier with no policy
bundle denies with bundle_policy_missing; a request that matches no route denies with
bundle_route_missing.
The confirmation claim in a passport: the key or identity that must be proven at request time.
Request proof only verifies when it is produced by the key the cnf claim binds.
Derived key
Section titled “Derived key”A client key issued by Control after successful enrollment against a Trust Anchor Source (enrollment plane). It inherits the selected existing client’s protected-resource policy; its effective lifetime is the earlier of the enrollment policy’s maximum key lifetime and the identity proof’s expiry.
Enrollment policy
Section titled “Enrollment policy”A Control policy that binds one exact verified Trust Anchor Source revision to one existing client, with an approval mode and a maximum key lifetime. Referenced by workloads through an opaque policy reference generated by Control — never by internal IDs.
Fail-closed
Section titled “Fail-closed”The verifier’s posture when required state cannot be established: deny rather than allow. A
bundle too stale for its route’s freshness class denies with stale_bundle_fail_closed, and
Redis-backed replay state fails closed rather than skipping the replay check.
Freshness class
Section titled “Freshness class”The per-route bound on how stale a bundle may be: realtime, bounded, or offline-ok. An
unknown or invalid class denies with bundle_freshness_unknown; a bundle staler than the route
allows denies with stale_bundle_fail_closed.
The unique passport ID claim. Each accepted jti is consumed exactly once, so a second
presentation of the same passport denies with jti_replay.
Passport
Section titled “Passport”A short-lived, audience-scoped, proof-bound authorization artifact derived from workload
identity — not a long-lived bearer token. Its minimum claims are iss, sub, aud, iat,
exp, jti, trust_domain, and cnf.
Replay consumption
Section titled “Replay consumption”The atomic consume of each accepted jti, backed by memory (single instance) or Redis
(multi-replica), so the same passport and proof cannot be used twice. Policy-level denials run
before consume, so a malformed or unauthorized request never burns a victim’s jti.
Request binding
Section titled “Request binding”Tying a passport to one exact request by signing a transcript-v1 transcript over the request
shape. Tampering with any bound element denies with request_binding_mismatch; a malformed or
unverifiable proof denies with invalid_request_proof.
Route policy
Section titled “Route policy”The per-route portion of the policy bundle: which sources a route accepts (allowed_sources),
the minimum signer class (required_key_binding), and the freshness rules (freshness_class).
The verifier evaluates route policy locally on every request.
Signed bundle
Section titled “Signed bundle”Trust material or a policy bundle whose reviewed output has been signed with
trustplane bundle sign and can be checked with trustplane bundle verify. Production-style
adapter loading should require bundle-signing public keys and reject unsigned or tampered
material unless an explicit local dev flag is selected.
Signer class
Section titled “Signer class”The key-binding strength taxonomy, ordered weakest to strongest:
software < remote_kms < hardware_local < attested_workload. A route can demand a minimum via
required_key_binding; a key class below the minimum denies with insufficient_key_binding.
Off-host key-reuse prevention is only claimed for hardware_local and attested_workload.
Source rule
Section titled “Source rule”One entry in a route’s allowed_sources: an issuer, trust_domain, subject_exact or
subject_prefix, required_key_binding, and optional provenance_policy and context_policy.
The verifier accepts a request only when a source rule matches the request’s issuer, trust
domain, subject, and key binding.
transcript-v1
Section titled “transcript-v1”The canonical request-binding format the proof signs over. It binds the request’s method,
authority, path, query, selected headers, nonce, body hash, audience, route_id, passport
jti, issued-at bucket, and key binding into a signed string that is byte-identical across
conforming languages.
Trust anchor (Auth route-source authorization)
Section titled “Trust anchor (Auth route-source authorization)”Request-plane term. A trusted issuer or broker public key the verifier accepts signatures from, evaluated per request against route policy. A verifier can hold multiple anchors at once, so one route can authorize callers from different issuers and trust domains — each constrained by its own source rule. Distinct from Control’s enrollment-time Trust Anchor Sources; see Two trust planes.
Trust Anchor Source (Control enrollment)
Section titled “Trust Anchor Source (Control enrollment)”Enrollment-plane term. A Control-registered source for validating external workload evidence once, at enrollment time — for example an OIDC JWKS source pointing at a Kubernetes cluster’s OIDC issuer — before a derived client key is issued. Distinct from the per-request Auth trust-anchor entries above, and not Control’s bundle-signing trust root. See Two trust planes and the OIDC JWKS enrollment runbook.
Trust bundle
Section titled “Trust bundle”The document of trusted issuer and broker public keys, keyed by kid, that the verifier uses
for local signature verification. Also called trust material; it is distributed as a TrustPlane
bundle document and mounted as a local file.
Trust domain
Section titled “Trust domain”The administrative trust boundary named in a passport’s trust_domain claim. Source rules match
on it, and a passport from a trust domain the route does not allow denies with
source_trust_domain_mismatch.
TrustPlane
Section titled “TrustPlane”The platform: TrustPlane Auth (the enforcement plane) and TrustPlane Control (the governance plane), two distinct components designed to be used together under one operating model — control centrally, enforce locally. See What is TrustPlane?.
TrustPlane Control
Section titled “TrustPlane Control”The governance plane of the TrustPlane platform and the enterprise offering, delivered as managed SaaS — the cockpit for enrollment, signed policy releases, revocation, fleet visibility, audit, and operator access (RBAC). It manages bundle distribution, revocation, audit ingestion, approvals, policy history, fleet inventory, and status across many Auth deployments, and it is never a hot-path dependency: it is not called synchronously for each protected request.
TrustPlane Edge
Section titled “TrustPlane Edge”The self-hosted deployment of TrustPlane Control, for organizations that need the governance plane inside their own environment, with advanced, tailored capabilities.
Two trust planes
Section titled “Two trust planes”The distinction between Auth route-source authorization (per-request route policy in signed bundles) and Control enrollment Trust Anchor Sources (one-time validation of workload evidence before a derived client key is issued). See Two trust planes.
Verifier
Section titled “Verifier”The enforcement point that says allow or deny: the brownfield adapter, library middleware
(pkg/middleware/http) inside a Go service, or a gateway or sidecar. It checks the passport and
proof locally, using public keys from a trust bundle, with no mandatory online call.
Workload identity
Section titled “Workload identity”Who the machine is, from an identity provider: SPIFFE/SPIRE (for example an X.509-SVID), an OIDC/JWT issuer, or a TrustPlane-native local issuer for development, demos, and conformance tests. TrustPlane Auth is SPIFFE-compatible, not SPIFFE-required.