Skip to main content
The Product Key Registry is the canonical, signed answer to two enterprise questions: “how do I independently confirm this signature came from a genuine AlgoVoi key?” and “what happens when that key rotates?” It is additive. Every AlgoVoi product receipt is already self-verifying — the public key and kid travel inside the signed envelope, and the free verifier checks it with zero network calls. The registry adds an independent trust path: a signed, discoverable record of which keys AlgoVoi operates, the key-custody model for each product, and a cross-signed lineage so a retired key stays followable to its successor.

​
The signed registry

https://api.algovoi.co.uk/.well-known/algovoi-product-keys.json
A single Falcon-1024 signed document (same root key, trust model, and monthly re-sign discipline as the ATB hub registry). It carries:
  • algovoi_operated_keys — the keys AlgoVoi signs with, fully specified (algorithm, kid, public key, what each is used for): the gateway Ed25519 (hosted compliance receipts / JWS) and the two Falcon-1024 ATB keys (registry root, certificate issuance).
  • products — one entry per commercial product with an honest key_custody field.
  • key_lineage — a genesis anchor per operated key, ready to carry cross-signed rotation proofs.

​
Key custody — who holds the signing key

CustodyMeaning
algovoi-operatedAlgoVoi signs and rotates the key; it is fully specified in the registry and published for verification.
buyer-onpremThe product is deployed on the operator’s own infrastructure; the buyer generates the signing key at install. Receipts remain self-verifying via their embedded key, and the buyer maintains the key-rotation lineage on their side.
hybridThe product offers both a hosted (AlgoVoi-operated) signing endpoint and an on-prem SDK (buyer-custody). The entry’s modes array names each path. Compliance Gate is the example: the hosted endpoint signs compliance receipts with the operated Ed25519 JWS key, while the SDK signs buyer-side with Falcon-1024.
Most commercial SKUs (Records Vault, Travel Rule, Audit Log, Agent Passport, …) are buyer-onprem — your keys never leave your estate. A few (e.g. Compliance Gate) are hybrid: a hosted convenience path under an AlgoVoi-operated key alongside the on-prem SDK. The registry documents the model honestly rather than implying AlgoVoi holds your keys.

​
Verify it yourself

The free verifier authenticates the registry and any kid offline — no AlgoVoi code, just pqcrypto + rfc8785: 
python algovoi_verify.py product-keys algovoi-product-keys.json
# PASS registry kid binds to its public key cf36870dd671f95a
# PASS Falcon-1024 signature over registry payload
# RESULT: PRODUCT REGISTRY VERIFIED

python algovoi_verify.py product-keys algovoi-product-keys.json <kid>
# resolves <kid> to an AlgoVoi-operated key, or flags it as buyer-custody

​
Per-product DID

Each product resolves as a did:web: 
did:web:api.algovoi.co.uk:products:<sku>
  -> https://api.algovoi.co.uk/products/<sku>/did.json
The DID document links to this registry and the product’s documentation, and states the product’s key-custody model and signature algorithm — a stable, resolvable identifier per product.

​
Key rotation lineage

Records that outlive their signing keys need provable continuity across rotations. The registry carries an F7 cross-signed lineage (the same mechanism behind Recovery Vault and the conformance vectors epi_pqc_v0 set): on rotation, the old key authorises the successor and the new key counter-signs. A verifier follows the chain from any retired kid to the current one, so everything the retired key signed stays trustable.
Buyer-onprem products run this same lineage mechanism on their own keys (included with Crypto-Agility); the registry’s lineage covers the AlgoVoi-operated keys.