Skip to content
TrustPlane

Standards alignment

If your environment already speaks JWT, JWKS, DPoP, or OAuth, you need to know how TrustPlane Auth fits alongside those standards. The short version: TrustPlane Auth is standards-compatible and bearer-minimizing. It is not anti-OAuth, and it is not a plain bearer-token OAuth profile.

The current contract

Section titled “The current contract”

The current Auth contract remains:

  • passport-v1 is a TrustPlane JWT: a short-lived, signed authorization artifact with issuer, subject, audience, expiry, JTI, trust domain, confirmation, provenance, and context claims.
  • transcript-v1 is the canonical proof-bound request transcript. It binds method, authority, path, query, selected headers, nonce or time bucket, body hash, audience, route_id, passport JTI, issued-at bucket, and key-binding class to the proof signature.
  • Signed local trust material and signed local policy bundles remain the verifier’s current source of issuer keys, route policy, allowed sources, required signer class, provenance constraints, context constraints, freshness, and deny reasons.

Standards interop is additive. HTTP Message Signatures, DPoP, OAuth token exchange, OAuth introspection, MCP discovery, and OAuth discovery bridges are not currently supported. If added, they may bridge TrustPlane decisions into ecosystems that expect those surfaces, but they must preserve the TrustPlane verification contract instead of replacing it.

How TrustPlane maps to each standard

Section titled “How TrustPlane maps to each standard”
Standard or surface TrustPlane mapping Current posture
JWT/JWKS / RFC 7517 passport-v1 remains a TrustPlane JWT/JWS-style artifact. Issuer public keys may be represented as JWK/JWKS material and mirrored into signed local TrustPlane bundles. Compatible key and token shape. JWKS does not replace request proof, route policy, signer-class policy, provenance/context checks, replay checks, or bundle freshness.
HTTP Message Signatures / RFC 9421 RFC 9421 is a planned wire-format bridge for signing HTTP components. Any use must cover the same effective request semantics as transcript-v1 or carry an unambiguous mapping to it. Planned additive interop; not currently supported. It is not a replacement for the current canonical transcript-v1 verifier path.
DPoP / RFC 9449 DPoP is a planned OAuth-facing proof-of-possession bridge around method, URI, nonce, token hash, and proof key material. Planned additive interop; not currently supported. DPoP proof alone is not enough unless TrustPlane request binding, replay consume, route/source policy, signer-class policy, provenance/context constraints, freshness, and deny reasons are preserved.
OAuth token exchange / RFC 8693 Token exchange is a planned backend or egress bridge where a verified TrustPlane request is exchanged for a downstream provider token or backend assertion. Planned compatibility bridge only; not currently supported. It is not the core TrustPlane model and must not create ingress bearer-only acceptance.
OAuth introspection / RFC 7662 Introspection is a planned backend compatibility surface for systems that need an online active/metadata decision instead of local TrustPlane verification. Planned compatibility bridge only; not currently supported. It does not replace local verification, signed bundles, proof binding, replay consume, or policy checks.
MCP/OAuth discovery surfaces Discovery may advertise TrustPlane-supported issuer metadata, JWKS locations, passport-v1, transcript-v1, proof modes, and planned bridge endpoints. Discovery is metadata, not a verification shortcut. It must not imply that TrustPlane-protected ingress accepts plain bearer OAuth tokens without proof-bound verification.

Protect existing services today

Section titled “Protect existing services today”

Current brownfield ingress support is trusted_boundary adapter mode:

caller -> trustplane-adapter -> existing upstream

The adapter is the enforcement point. It verifies the TrustPlane passport and transcript-v1 proof, checks the signed local policy bundle, consumes replay state only after acceptance, and forwards TrustPlane context headers to an upstream inside the trusted boundary.

The upstream may trust those forwarded headers only because network placement, gateway configuration, and operational controls prevent untrusted callers from bypassing the adapter or forging adapter-to-upstream context.

Invariants every bridge must preserve

Section titled “Invariants every bridge must preserve”

Every standards bridge must preserve these TrustPlane invariants:

  • Request binding remains canonical until an accepted proof profile defines an equivalent or stronger mapping.
  • Replay state is consumed atomically only on accepted presentations.
  • Route identity, method/path policy, issuer, trust domain, subject exact or prefix, and allowed_sources still gate acceptance.
  • Signer classes keep their current meanings and ordering: software, remote_kms, hardware_local, and attested_workload.
  • prov and ctx policy hooks remain part of the verifier decision.
  • Stale or unverifiable trust and policy bundles fail closed according to route freshness rules.
  • Deny outcomes keep stable reason codes suitable for tests, audit, and operator diagnosis.

Non-goals

Section titled “Non-goals”

This posture does not add runtime implementation, SDK extraction, Control behavior, bearer-only OAuth ingress, deployment changes, cloud infrastructure, token exchange endpoints, introspection endpoints, or discovery endpoints. It defines how planned compatibility bridges must preserve the proof-bound Auth model.

Next steps

Section titled “Next steps”