Skip to main content

Route policy map

One TrustPlane adapter can protect many routes. Each request is matched by method and path, then the adapter evaluates the route's allowed_sources.

Acme can use one adapter for:

  • GET /orders
  • POST /orders
  • GET /invoices
  • GET /customers/{id}

Each route can accept a different mix of software/JWKS, EC2-style, SPIFFE/SPIRE, or external automation sources.

Method/path matching​

{
  "route_id": "acme.orders.read",
  "method": "GET",
  "path_template": "/orders",
  "audience": "acme.orders",
  "freshness_class": "bounded",
  "max_staleness_seconds": 300
}

In request route-policy mode, the adapter derives the route from the actual HTTP method and path. A proof for GET /orders cannot be replayed as POST /orders, and a proof for /orders cannot be reused for /invoices.

Allowed sources​

{
  "route_id": "acme.orders.read",
  "allowed_sources": [
    {
      "issuer": "https://issuer.acme.example/external-jwks",
      "trust_domain": "acme.example.external",
      "subject_exact": "external:jwks:partner-orders",
      "required_key_binding": "software"
    },
    {
      "issuer": "https://issuer.acme.example/ec2-jwks",
      "trust_domain": "acme.example.ec2",
      "subject_prefix": "aws:ec2:us-east-1:",
      "required_key_binding": "software"
    },
    {
      "issuer": "https://issuer.acme.example/spire",
      "trust_domain": "example.local",
      "subject_prefix": "spiffe://example.local/ns/orders/sa/",
      "required_key_binding": "attested_workload"
    }
  ]
}

The verifier accepts a request only when one source rule matches the request's issuer, trust domain, subject selector, and minimum signer class. Software sources can coexist with attested_workload sources on the same route.

What TrustPlane Auth decides​

Before the request reaches upstream, the adapter verifies:

  • the passport signature and issuer key
  • audience, expiry, trust domain, and subject
  • method/path/route request binding
  • selected headers and body hash where configured
  • replay consumption
  • route freshness policy
  • source policy and minimum signer class

If a check fails, the adapter denies before forwarding.

What upstream still decides​

The upstream application still owns business authorization and RBAC. TrustPlane Auth answers: "is this caller allowed to present a verified proof for this route?" The upstream answers: "given this verified caller and request, what business action is allowed?"

That separation lets a brownfield API adopt proof-bound caller verification without moving all domain authorization logic into the adapter.