Standards interoperability

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 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. Future HTTP Message Signatures, DPoP, OAuth token exchange, OAuth introspection, MCP discovery, or OAuth discovery support may bridge TrustPlane decisions into ecosystems that expect those surfaces, but they must preserve the TrustPlane verification contract instead of replacing it.

Standards mapping

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 can be a future 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.	Additive future interop. It is not a replacement for the current canonical transcript-v1 verifier path.
DPoP / RFC 9449	DPoP can be a future OAuth-facing proof-of-possession bridge around method, URI, nonce, token hash, and proof key material.	Additive future interop. 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 can be a future backend or egress bridge where a verified TrustPlane request is exchanged for a downstream provider token or backend assertion.	Future compatibility bridge only. It is not the core TrustPlane model and must not create ingress bearer-only acceptance.
OAuth introspection / RFC 7662	Introspection can be a future backend compatibility surface for systems that need an online active/metadata decision instead of local TrustPlane verification.	Future compatibility bridge only. 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 future 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.

Current brownfield ingress

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.

Required invariants

Every standards bridge must preserve these TrustPlane invariants:

• Request binding remains canonical until a future 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

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 future compatibility should preserve the proof-bound Auth model.