Open-Predicate Standardization
A short roadmap note: how the Probity predicate types — security-verdict
and adversarial-execution-evidence above all — become an open standard the incumbent
admission controllers recognize natively, so an enterprise's existing Kyverno /
sigstore policy-controller can demand and verify a Probity verdict without a single
Probity-authored component in the trust path.
This is the demand-pull other half of the admission bundle in
deploy/admission/: that bundle shows the
verdict is already enforceable today by an incumbent pointed at our public key;
this note is about making the predicate type a recognized member of the broader
in-toto / SLSA predicate ecosystem so recognition is the default, not a
per-deployment configuration.
Why standardize the predicate type
What makes this durable is that the value lives in the verifiable verdict an existing admission controller can consume directly, not in a gate we ship. That value grows as the predicate type becomes something a tool recognizes out of the box:
- An admission controller, registry, or CI gate keys off
predicateType. The more widelyhttps://in-toto.io/attestation/adversarial-execution-evidence/v0.7is a known predicate type, the less configuration a consumer needs and the higher the cost of a competing, incompatible verdict schema. - A stable, published predicate type with a published schema and a conformance suite is exactly the shape the in-toto attestation framework and the SLSA predicate conventions are built to register and route.
What is already in place
| Requirement for a recognized open predicate | Status | Where |
|---|---|---|
| A stable predicateType URL under a controlled namespace | DONE | https://getprobity.dev/predicate/v1/<name> for the Probity-namespace types; the flagship evidence predicate is proposed under the in-toto namespace as https://in-toto.io/attestation/adversarial-execution-evidence/v0.7 |
| A published predicate schema (machine-readable) | DONE | spec/schemas/v1/adversarial-execution-evidence.schema.json (draft 2020-12), the on-wire SSOT; prose in spec/v1/adversarial-execution-evidence.md |
| A predicate-agnostic signing envelope | DONE | spec/v1/signing-envelope.md — DSSE PAEv1 + ed25519 + RFC-7638 keyid |
| A conformance suite any tool can run offline | DONE | spec/v1/conformance.json + signed bundles; the @probity/verify package carries it (packages/verify/) |
| Reject vectors proving fail-closed behavior | DONE | packages/verify/vectors/aee-v06/ (bare v0.7 in-toto statements — unknown predicateType, stripped catchPolicy, ...; inline-signed with an ephemeral key for the crypto rails) |
| A binding chokepoint mirrored across runtimes | DONE | bindings.ts (TS) + the Python verdict_bundle verifier + deploy/admission/rego/probity_admission.rego (rego) |
| A discoverable verification-key endpoint | SHIPPED (2026-06-29, DEC-20260630-001) | https://getprobity.dev/.well-known/verification-keys — served from website/public/.well-known/verification-keys.json; a keyid-resolving verifier fetches the public key (427a1092… → probity-mcp.pub) instead of pinning it inline, which is what an incumbent's "trusted issuer" configuration wants |
An admission-freshness field (issuedAt) | SPECIFIED (2026-07-06) | OPTIONAL top-level issuedAt (RFC3339 UTC) in spec/schemas/v1/adversarial-execution-evidence.schema.json + spec/v1/adversarial-execution-evidence.md; the Kyverno freshness policy in deploy/admission/kyverno/ gates on it (deny if older than the consumer's threshold, e.g. 168h) and fails closed while it is absent — the threshold is the consumer's policy, not part of the standard; producer emission is the remaining code change |
The format is therefore already an open standard in substance: vendor-neutral,
offline-verifiable against a configurable trust anchor (the envelope explicitly
forbids hardcoding probity.pub as the only acceptable key), with a published
schema and a runnable conformance suite.
What native recognition still needs
Two items remain open, both process (the discoverable key endpoint and the issuedAt
freshness field, formerly listed here, have shipped / been specified — see the table
above; producer emission of issuedAt is the one remaining code change).
-
Submit the predicate type to the in-toto / SLSA predicate registry. in-toto maintains a list of known predicate types; SLSA references predicate conventions.
adversarial-execution-evidenceis authored FOR that namespace (https://in-toto.io/attestation/adversarial-execution-evidence/v0.7), positioned as the active-stimulus sibling to the passiveruntime-tracefamily: bounded adversarial stimulus, per-attack-to-catch attribution, and a cryptographically committed coverage bound, with a fusedresultthat is a deterministic, severity-independent, offline-recomputable reduction of the enclosed evidence (the in-tototest-resultprecedent) — deliberately NOT an SVR-class delegated policy decision. Register it (with links to the schema + conformance suite) so registry-aware tooling resolves the type without per-deployment config; the envelope IS DSSE with PAEv1. -
A neutral-governance signal. Broad recognition benefits from genuine multi-vendor governance: a public
CHANGELOG/versioning policy (the two-axis envelope-vs-predicate-schema split is already documented), an explicit deprecation policy, and an invitation for other producers to emit verdicts under their own keys (which the configurable trust root already permits). The format does not name or assumeprobity.pub; that neutrality is the credible-open-standard hook.
Honesty / scope
- Standardizing the predicate does not standardize the runtime. The runtime that produces a sound verdict (the substrate, the corpus, the gate engine) stays proprietary; the open surface is the verdict shape and its offline-verify contract. A third party can verify a verdict's integrity, provenance, subject binding, and the offline-checkable bindings — it cannot, from the verdict alone, re-derive the producer or confirm the assessment taxonomy is complete (the verdict specs say this plainly).
- Registry submission is an external-party action with its own timeline; it is
named here as roadmap, not as shipped. Both remaining items (registry filing,
governance) are process; the filing mechanics and submission draft are prepared in
research/91-standards-filing-2026-07-06/. Producer emission of the now-specifiedissuedAtfield is a one-field code change.