VAID capabilities
Status below is rendered from capabilities.json, the single source of truth in the
vaid repo, vendored here and drift-checked in CI. Prose does not assert status; this does.
| Capability | Status | Where it lives | What it is | Blocked on |
|---|---|---|---|---|
| Request proof-of-possession verification | ✓ Shipped | vaid-pop 0.2.0 (rust) · vaid-pop 0.1.0 (python) · vaid-pop 0.3.0 (typescript) | A request's proof-of-possession is verifiable by any holder of the signer's public key, offline, no service. All three implementations ship the conformance firewall as an installable executable (`vaid-pop-conformance`); Rust gained one at 0.2.0, closing the gap where its only check ran from a repository checkout. A consumer therefore reproduces the frozen digest and signature from the artifact they received, in any of the three. | , |
| Reference mint (issuance, delegation, attenuation) | ✓ Shipped | vaid-mint 0.1.2 (rust) · vaid-mint 0.1.3 (python) · vaid-mint 0.3.0 (typescript) | A reference mint issues VAIDs and mints attenuated child VAIDs; published and installable. Rust and Python version independently, Python 0.1.3 is a docs-only PyPI re-release over the same 0.1.2 behaviour, so byte-for-byte agreement is asserted at the conformance-vector level, not the version number. | , |
| Cross-language conformance | ✓ Shipped | vaid-pop 0.1.0 (rust) · vaid-pop 0.1.0 (python) · vaid-mint 0.3.0 (typescript) | Rust and Python reproduce a frozen conformance vector byte-for-byte. | , |
| LangChain request-signing adapter | ✓ Shipped | vaid-langchain 0.1.0 (python) | A LangChain adapter that signs requests under the VAID proof-of-possession contract. | , |
| Public-key VAID document verification | ✓ Shipped | vaid-mint 0.2.0 (rust) · vaid-mint 0.2.0 (python) · vaid-mint 0.3.0 (typescript) | Verifying a VAID document's authenticity from the issuer's public key alone, no issuer instance. | , |
| Three-state, lineage-aware revocation seam | ✓ Shipped | vaid-mint 0.2.0 (rust) · vaid-mint 0.2.0 (python) · vaid-mint 0.3.0 (typescript) | Revocation checked over a VAID's full lineage, three-state, revoking a parent revokes its children, and a status that cannot be determined (Unavailable) fails closed. THE DEFAULT IS FAIL-CLOSED FROM vaid-mint 0.9.0, published on crates.io, PyPI and npm. Every vaid-mint published before 0.9.0 constructs the issuer with an assume-nothing-revoked in-memory store, which vouches NotRevoked for every VAID it was never told about and cannot detect its own restart, a fail-open posture reached by assumption, so a VAID revoked before a restart verifies clean. See GHSA-p336-fc9m-vcq4. On an affected version an integrator gets fail-closed behaviour only by holding the store absent or injecting a durable RevocationCheck. See revocation-fail-closed-default. | , |
| Fail-closed revocation by default | ✓ Shipped | vaid-mint 0.9.0 (rust) · vaid-mint 0.9.0 (python) · vaid-mint 0.9.0 (typescript) | ReferenceIssuer's revocation store starts ABSENT, so verification fails closed until revocation state is loaded (spec R.4.5), and durable revocation becomes two stores (R.4.6: revoked set AND lineage). Breaking in all three languages. Released as vaid-mint 0.9.0 on crates.io, PyPI and npm. Each leg was verified from a clean install against the packaged conformance firewall, and all three reproduce the same frozen mint_v1 digest. Security advisory for the fail-open default this replaces: GHSA-p336-fc9m-vcq4. | , |
| TypeScript implementation (third conforming language) | ✓ Shipped | vaid-pop 0.3.0 (typescript) · vaid-mint 0.3.0 (typescript) · vaid-client 0.3.0 (typescript) | A third conforming implementation in TypeScript, minting with attenuation, public-key VAID verification, request proof-of-possession, and the three-state revocation seam. It reproduces all five frozen conformance vectors byte-for-byte in CI alongside Rust and Python. Published on npm (vaid-pop, vaid-mint, vaid-client), landing at 0.3.0, the version this capability LANDED IN, not an install instruction: the three packages version independently and have moved since. What you get installing today is registry-checked separately and must never be sourced from this file. Each ships a packaged conformance firewall, `npx -p vaid-mint vaid-mint-conformance` and the two siblings, which reproduces the frozen digests from the INSTALLED package, so a consumer can check the artifact they actually received rather than trusting this claim. | , |
| Third-party attenuation (authority) verification | ✓ Shipped | vaid-mint 0.4.0 (rust) · vaid-mint 0.4.0 (python) · vaid-mint 0.4.0 (typescript) | A third party holding the issuer's kernel PUBLIC key and the ancestor documents a presenter supplies can verify that a child's authority is within its parent's, at every hop, scope, capabilities, expiry, and the qualified (trust_domain, tenant_id) pair. A child's expiry is contained by its parent's, and a chain with a lapsed ancestor is refused rather than reported attenuated. Containment reuses the mint-time matchers, so verify-time cannot drift from the check that gated issuance. Achieved by detached chain presentation (ADR-0003) with NO change to the VAID document: no new field, no sig_version bump, no mint_v1 re-freeze. That last sentence is a statement about ADR-0003 and about nothing else: it describes what THAT change cost, not the current state of the wire format. ADR-0009 later typed scope_boundary's entries, which did move sig_version to 4 and did re-freeze mint_v1, containment reuses the same matchers over the typed entries, so the capability described here is unchanged by it. Pinned cross-language by chain_v1.json. LIMITS, stated because they are load-bearing: the presenter must retain and present the ancestors, so a leaf whose ancestor documents were discarded has unverifiable attenuation; and full-chain verification requires full-chain disclosure. | , |
| Third-party end-to-end lineage verification | ✓ Shipped | vaid-mint 0.4.0 (rust) · vaid-mint 0.4.0 (python) · vaid-mint 0.4.0 (typescript) | A third party can walk a full delegation chain from a presented bundle: every document authenticated, every hop pinned against the signed parent_vaid, and any gap, an unpresented ancestor, a cycle, an implausible depth, failing closed as attenuation-unverifiable rather than attenuation-satisfied. Chains that cross kernel keys additionally require a detached consent attestation from the issuer that minted the parent (attestation_v1.json), because nothing in a VAID document otherwise proves the parent consented; a cross-key hop without valid consent never verifies. LIMITS: revocation is NOT consulted by chain verification anywhere on the chain, and the leaf's OWN expiry is not consulted either, expiry is enforced BETWEEN hops, so a lapsed ancestor is refused, but the presented leaf must still be checked by the caller (vaid#76); and consent is time-bounded rather than revocable, retraction inside an attestation's window needs durable revocation, which this implementation does not provide (docs/spec/revocation.md R.4.6, docs/spec/consent-attestation.md C.6). | , |
| Cross-deployment VAID verification | Planned | , | Verifying a VAID issued by one deployment from another. v3 (ADR-0004) supplies the missing identifier, the document names its issuing trust domain and commits to the key that signed it, and the publication route exists: the SYNTHERA substrate's kernel public key is published, with its RFC 7638 thumbprint in three independent channels, so a third party can obtain the key and confirm it is the right one (see /trust-anchor). The substrate emits both v3 identity fields today: the revision serving 100% of substrate traffic is built from synthera 8556828, whose crates/synthera-types/src/vaid.rs sets sig_version 3, trust_domain and kernel_key_thumbprint on every document it constructs; and a production VAID captured on 2026-08-07 (synthera docs/evidence/vaid-third-party-verification-2026-08-07/production-vaid.json) verifies VALID under published vaid-mint 0.7.0 against the published anchor key, by the open standard's own verifier, with no substrate cooperation. Authenticity across deployments therefore works today (verified 2026-09-21). What remains is not a deploy: (1) the substrate's trust_domain is 'substrate.internal', reserved by RFC 6761, and docs/trust-anchor.md says a conforming verifier SHOULD refuse to bind a trust bundle to a special-use name, so key selection works by thumbprint while domain binding does not exist, pending an issuer-naming decision that is irreversible once verifiers bind to it; and (2) per synthera ADR-0034 the substrate's document carries an additional external_identity member, so it is a superset of the standard's document rather than the same document, it verifies only because ADR-0006 canonicalizes over presented bytes, and a verifier that re-projects into its own struct would reject it. | an issuer-naming decision: the substrate's trust_domain is the RFC 6761 special-use name 'substrate.internal', so no trust bundle can be bound to it. Substrate adoption of the v3 identity fields (synthera ADR-0034) is DONE and serving; the kernel public key publication route (synthera#16) is CLEARED, published 2026-08-03 |
When a blocking PR merges, the manifest flips that capability to shipped and every badge,
here and on any page using <Capability>, follows automatically. CI fails if a
shipped version is not published, or if a capability is still marked roadmap while its blocker PR
has merged.
This board answers one question: what a capability is. Who operates it is a separate axis and this table does not carry it, a capability can be shipped in the code and run by nobody. The two ways to run this covers that axis.
SYNTHERA is the trust layer for multi-agent systems: every agent gets a verifiable identity, scoped authority and a tamper-evident record, so software from different teams, vendors and frameworks can act on each other’s behalf without custom glue between every pair.
Discuss a technical evaluation.
Bring this table to your own review and we'll walk through what's demonstrable today.