Security posture

Before you put TrustPlane Auth in front of production traffic, you want to know what it actually protects you from — and what it doesn’t. This section lays out the security posture behind TrustPlane Auth’s design decisions, so you can judge for yourself whether the guarantees match your threat model.

The core stance

TrustPlane Auth is built around a small set of security principles that show up in every page of this section:

• Short-lived, proof-bound artifacts. A passport-v1 is a short-lived, signed authorization artifact, and a transcript-v1 proof binds it to one specific request — method, path, body hash, audience, route, and passport JTI. Possession of a stolen artifact is not enough; the attacker also needs the signing key, the exact request, and a window of a few seconds before the legitimate caller’s jti is consumed.
• Local verification, not online lookups. Verifiers check requests against signed local trust material and signed local policy bundles. Verifiers only ever hold public keys — private keys stay with the issuer, broker, or KMS.
• Fail-closed freshness. High-risk routes deny on stale bundle or revocation material. Offline behavior is per-route (freshness_class), never a blanket “fail static.”
• Least standing privilege. Acceptance is gated by route identity, audience, issuer, trust domain, subject, allowed sources, and required signer class — and replay state is consumed atomically, exactly once, only on an otherwise-valid presentation.

Just as important: TrustPlane Auth is careful to say exactly what each configuration proves and what it does not. Overclaiming security is itself a vulnerability, so these pages spell out the acceptance matrix, the trust tiers, and the residual risks in plain terms.

What this section covers

• Security model — what a stolen passport can and cannot do, the key-theft and RAT acceptance matrix, trust-anchor source tiers, how attested_workload actually works, and fail-closed behavior.
• Standards alignment — how TrustPlane Auth relates to JWT/JWKS, HTTP Message Signatures, DPoP, OAuth token exchange, introspection, and discovery surfaces, and the invariants any standards bridge must preserve.
• OAuth and backend compatibility — the backend compatibility tiers: trusted_boundary ingress today, and the future backend_jwt and oauth_compat_egress bridges that sit strictly after proof-bound verification.

Next steps

• Start with the security model to see the threat coverage in detail.
• For how verification fits into the request path, see How it works.