Skip to main content

Conformance vectors

Conformance vectors are stable contract examples for people building TrustPlane-compatible clients, SDKs, brokers, MCP tools, n8n integrations, and workflow agents. They describe what a compatible implementation must produce or accept for the locked TrustPlane Auth contract shapes.

Use them as fixtures for repeatable tests. They are not live credentials, not environment configuration, and not a substitute for your own release security review.

What they cover​

The suite is designed to catch differences that would make one implementation disagree with another at request time:

  • transcript-v1 canonicalization, including method, authority, path, query, selected headers, nonce, body SHA-256, audience, route ID, passport ID, issued-at bucket, and key binding.
  • Body SHA-256 expectations for empty, textual, and structured request payloads.
  • Passport claim shape, including issuer, subject, audience, expiry, trust domain, passport ID, and confirmation material.
  • Signer taxonomy and ordering: software < remote_kms < hardware_local < attested_workload.
  • Bundle source-rule semantics, including allowed source matching and signer-class minimums.
  • Broker IPC request and response shapes for local issuance paths.

Each vector should be read as contract evidence: given this input, a compatible implementation reproduces the exact canonical bytes, hashes, source-rule decisions, and signer ordering.

Fixture safety​

Conformance vectors are test fixtures.

  • Public key material in fixtures is test-only.
  • No private keys are included.
  • No live environment access is included.
  • No bearer credential, cluster access file, cloud credential, or production trust material should be inferred from a vector.
  • Do not copy fixture identities into production policy without replacing them with your own reviewed issuer, subject, source, and route rules.

Proof-bound passport shape​

Some passport fixtures are proof-bound. In those fixtures, the passport confirmation claim includes:

{
  "cnf": {
    "public_key_b64url": "..."
  }
}

A request-proof client must bind the request proof to the passport's public key material. Do not treat kid alone as sufficient. The key identifier helps lookup and diagnostics, but the cryptographic binding is to the public key material carried by the passport confirmation claim.

Compatibility checklist​

Before calling an implementation compatible with these vectors, test that it can:

  • Reproduce transcript-v1 canonical bytes exactly.
  • Reproduce body SHA-256 values exactly.
  • Preserve the passport claim names and proof-binding shape used by the fixtures.
  • Apply bundle source-rule semantics the same way as the vectors.
  • Compare signer classes using the locked ordering.
  • Preserve broker IPC field names and response semantics for local issuance paths.

The most common compatibility failures are whitespace differences in canonicalization, query or header normalization differences, body hashing over the wrong byte sequence, treating kid as the proof-bound key, and sorting signer classes alphabetically instead of by TrustPlane's locked taxonomy.