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, failing closed. | — |
| 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, and the qualified (trust_domain, tenant_id) pair. 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. 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 and expiry are NOT consulted by chain verification, 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 now 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). One thing remains: the substrate's deployed image predates ADR-0034 and so emits neither v3 identity field, meaning live-issued documents do not yet carry the issuer identity this capability reads. Until that deploy lands, a VAID issued by one deployment cannot be verified by another. | substrate adoption of the v3 identity fields (synthera ADR-0034) — 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.