Backend compatibility & OAuth egress

TrustPlane Auth supports backend compatibility as tiers around the same proof-bound authorization model.

Tier	Status	Scope
trusted_boundary	Current, supported	Adapter verifies the TrustPlane passport and transcript-v1 proof, applies local bundle policy, consumes replay state on acceptance, and forwards verified context headers inside a trusted boundary.
backend_jwt	Future, scoped	After TrustPlane verification, provide a backend-facing JWT/JWKS assertion for selected upstreams that want direct verification of a TrustPlane-issued assertion.
oauth_compat_egress	Future, scoped after target/provider selection	After TrustPlane verification, bridge to a third-party provider's OAuth/token-exchange/introspection flow when that provider requires OAuth.

OAuth egress is a bridge, not the TrustPlane core security model. The caller-to-TrustPlane side remains proof-bound, request-bound, route-scoped, replay-consumed, freshness-aware, signer-class-aware, and auditable.

Adoption paths

New APIs can start TrustPlane-native with the adapter in front of the service:

caller -> trustplane-adapter -> new API

Existing provider-owned APIs can adopt today through trusted-boundary adapter ingress:

caller -> trustplane-adapter -> existing API

Some brownfield APIs will eventually want direct verification:

caller -> TrustPlane verifier -> backend JWT -> upstream

That is the future backend_jwt tier. It is useful when an upstream wants a standard signed assertion and JWKS verification boundary of its own. It should be treated as hardening or compatibility for selected upstreams, not as a public bearer-token replacement for passport-v1 plus transcript-v1.

Some third-party SaaS APIs require their own OAuth tokens:

caller -> TrustPlane proof verification -> OAuth bridge -> third-party SaaS API

That is the future oauth_compat_egress tier. The OAuth token is a downstream compatibility artifact. It is not the TrustPlane caller credential and does not weaken the caller-to-TrustPlane verification contract.

Security invariants

All future backend compatibility tiers must preserve the TrustPlane caller-side invariants:

• Acceptance requires a valid proof tied to configured key material, not just possession of a bearer artifact.
• transcript-v1 remains canonical until an equivalent or stronger proof profile is accepted.
• Route identity, method/path policy, audience, issuer, trust domain, subject, and allowed_sources still gate acceptance.
• Replay state is consumed only after an otherwise accepted presentation.
• Signed trust and policy bundles, proof windows, and downstream assertions keep bounded validity and fail closed where route freshness policy requires it.
• Compatibility tokens must not erase signer-class policy.
• Allow and deny decisions must preserve stable reason codes and enough context to explain which TrustPlane decision produced any downstream backend assertion or OAuth request.

OAuth egress boundary

OAuth compatibility belongs on the egress side when the target backend requires OAuth. It must not create a new TrustPlane ingress mode where callers can skip proof-bound verification by presenting plain bearer OAuth tokens.

An acceptable future OAuth bridge starts with a verified TrustPlane decision, then derives the narrowest downstream OAuth request needed by the provider. Any future implementation should scope provider, audience, resource, tenant, route, subject, session, claims, token lifetime, and audit fields explicitly.

Non-goals

This page does not add runtime code, OAuth compatibility code, token endpoints, introspection endpoints, discovery endpoints, backend assertion endpoints, SDKs, Control behavior, deployment changes, cloud changes, or signed-bundle behavior changes.