> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Product Key Registry

> A Falcon-1024 signed registry of AlgoVoi signing keys with per product custody and did:web identities. Authenticate any signature and follow key rotation.

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](/rfc9421-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

<CodeGroup>
  ```text Endpoint theme={null}
  https://api.algovoi.co.uk/.well-known/algovoi-product-keys.json
  ```
</CodeGroup>

A single **Falcon-1024 signed** document (same root key, trust model, and monthly re-sign
discipline as the [ATB hub registry](/agent-trust-bench)). 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

| Custody                | Meaning                                                                                                                                                                                                                                                                                                                   |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`algovoi-operated`** | AlgoVoi signs and rotates the key; it is fully specified in the registry and published for verification.                                                                                                                                                                                                                  |
| **`buyer-onprem`**     | The 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.                                                                                  |
| **`hybrid`**           | The 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](/rfc9421-verifier) authenticates the registry and any `kid` offline — no
AlgoVoi code, just `pqcrypto` + `rfc8785`:

```bash theme={null}
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
```

The registry's signed payload uses RFC 8785 (JCS) canonicalization, and it canonicalizes
**byte-identically across eight independent implementations** (Python, Node.js, Ruby, PHP, Go, Rust,
Java, .NET) — the same discipline as the open [conformance corpus](/conformance-vectors). So the exact
bytes the Falcon-1024 signature covers are reproducible in your own stack.

## Per-product DID

Each product resolves as a [`did:web`](https://w3c.github.io/did-core/):

```text theme={null}
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](/recovery-vault) and
the [conformance vectors](/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.

<Info>
  Buyer-onprem products run this same lineage mechanism on their own keys (included with
  [Crypto-Agility](/crypto-agility)); the registry's lineage covers the AlgoVoi-operated keys.
</Info>