Skip to main content
This page is for organisations that want to operate an ATB Pass Certificate hub alongside AlgoVoi’s reference bench. The substrate is open: any party can issue certificates under the spec, and gateways can be configured to trust them. Inclusion in the AlgoVoi-signed Adopters Registry follows a documented conformance process.

​
What an ATB hub is

A hub is any service that:
  1. Measures AI agent behaviour against an adversarial test corpus
  2. Computes a reputation score per the documented methodology
  3. Issues a Falcon-1024 signed certificate that travels with the agent
  4. Publishes its public key for verifiers to fetch
The AlgoVoi Reference Hub is one example. Other organisations can operate hubs targeting different domains, different threat surfaces, or different audiences.

​
Why operate a hub

  • Reputation surface. Your assessment of an agent becomes a portable signal that earns the agent variable pricing at participating gateways.
  • Network effect on adoption. Every approved hub increases the value of the substrate; verifiers configured for the registry automatically trust new approved hubs without per-hub config.
  • No competition with AlgoVoi’s bench. The reference hub focuses on cross-chain agentic payments. Hubs operating in adjacent domains (specific frameworks, specific regulatory regimes, specific industry contexts) are complementary, not competitive.

​
Conformance requirements

​
1. Cryptographic primitives

  • Signature algorithm: Falcon-1024 (FIPS 206 / FN-DSA-1024). PQClean-encoded signatures are the canonical wire format; the spec page documents the encoding explicitly.
  • Canonicalisation: RFC 8785 (JCS). Signature is computed over rfc8785.dumps(payload).
  • Hashing: SHA-256 for the agent_id_hash, kid derivation, and profile_set_hash.
Reference implementation: any standard Falcon-1024 library + any RFC 8785 implementation. Working Python, Rust, and Java verifiers are available on request to applicants; the live application form at api.algovoi.co.uk/atb-hubs/apply runs the conformance checks server-side and returns a pass/fail transcript, which is the simplest validation path.

​
2. Certificate format

Hubs MUST issue certificates matching the schema in ATB Pass Certificate: 
{
  "payload": {
    "atb_cert_version": "1",
    "agent_id_hash": "<sha256 of double-hashed session cookie>",
    "score": 0.87,
    "score_components": { ... },
    "threshold": 0.70,
    "passed": true,
    "profile_set_hash": "<sha256 of JCS(sorted(profile_ids))>",
    "methodology_version": "<hub-tag>-v<major>.<minor>",
    "bench_issuer": "did:web:<your hub host>",
    "bench_kid": "<sha256[:16] of hub PK>",
    "issued_at": "...",
    "expires_at": "...",
    "ietf_anchor": "draft-hopley-x402-canonicalisation-jcs-v1-04"
  },
  "alg": "Falcon-1024",
  "kid": "...",
  "sig": "..."
}
The wire format is non-negotiable. Field additions are allowed if they sit alongside required fields; field removals or renames break conformance.

​
3. Discovery endpoints

A hub MUST expose: 
GET https://<hub host>/.well-known/atb-keys.json
GET https://<hub host>/sessions/me/certificate         (cookie-bearer)
GET https://<hub host>/sessions/{session_id_hash}/certificate  (operator)
The atb-keys.json document follows the published shape: 
{
  "issuer": "did:web:<hub host>",
  "ietf_anchor": "draft-hopley-x402-canonicalisation-jcs-v1-04",
  "keys": [
    {
      "alg": "Falcon-1024",
      "kid": "...",
      "public_key_pqclean_b64": "<1793-byte PQClean format>",
      "public_key_raw_h_b64":   "<1792-byte raw h polynomial>",
      "use": "sig",
      "key_size_pqclean_bytes": 1793,
      "key_size_raw_h_bytes":   1792
    }
  ],
  "signature_encoding": {
    "format": "pqclean_padded",
    "header_byte": "0x3a",
    "nonce_bytes": 40,
    "total_length_range": [666, 1280]
  },
  "cert_policy": {
    "threshold": <your threshold>,
    "ttl_days": <your TTL>,
    "minimum_adversarial_challenges": <your minimum>,
    "profile_set_hash": "<your set hash>",
    "profile_set_size": <count>,
    "methodology_version": "<your version tag>"
  }
}

​
4. Methodology versioning

Each hub declares a methodology_version string of the form <provider-tag>-v<major>.<minor>:
  • AlgoVoi reference: atb-v1.0
  • Acme example: acme-v1.0, acme-v2.0
A methodology version pins a specific scoring scheme, profile-set hash, and pass threshold. Changes to any of those bump the version. Gateways opt in per-methodology — being an approved hub does not auto-approve any methodology version a hub introduces. To register a new methodology version:
  1. Document the scoring formula, profile-set composition, and threshold in a publicly accessible spec page.
  2. Submit a pull request to the AlgoVoi spec repo adding the version to the methodology registry.
  3. After review (typically 7 days), the version is added to the next signed Adopters Registry update.

​
5. Apache 2.0 attribution

The substrate (canonicalisation discipline, certificate format, IETF anchor) is AlgoVoi-authored under Apache 2.0. Hub operators must:
  • Cite draft-hopley-x402-canonicalisation-jcs-v1 in the hub’s cert_policy.ietf_anchor field (or successor draft, once standardised).
  • Include AlgoVoi’s NOTICE text in any distributed code that uses the format.
The Apache 2.0 licence does not require renaming or rebranding. A hub may operate under its own name while implementing the substrate.

​
6. Operational requirements

To be eligible for inclusion in the AlgoVoi-signed Adopters Registry:
  • Uptime: 99% SLA over rolling 30 days for the issuance endpoint.
  • Key management: Hub signing key in HSM, dedicated VM, or equivalent. Not on a shared-tenancy host. Rotated at minimum annually.
  • Incident reporting: Compromise of the hub signing key MUST be reported to the AlgoVoi registry maintainer within 24 hours so the affected hub can be removed from the next registry update.
  • Conformance vectors: The hub MUST pass the published conformance vectors. Verified at application time and on every registry refresh.

​
Conformance test

The simplest path is to submit via the live application form once your hub is reachable. The form runs the conformance checks server-side against your published keys_url and returns a pass/fail transcript with diagnostic detail per check. The transcript covers:
  • keys_url_format — is a public https URL on a real hostname
  • keys_url_fetch — fetches successfully (200, follows redirects)
  • keys_url_json — response parses as JSON
  • keys_shape — keys[0] is a Falcon-1024 key
  • key_length — public key is 1793 bytes (PQClean) or 1792 bytes (raw_h)
  • kid_consistency — keys[0].kid matches sha256[:16] of the public key
  • cert_policy_present — cert_policy block exists
  • methodology_version_present — cert_policy.methodology_version exists
  • profile_set_size — cert_policy.profile_set_size >= 10
  • signature_encoding_format — declares pqclean_padded (or equivalent)
  • methodology_match — published methodology version matches applicant’s claim
Working reference verifiers (Python pqcrypto, Rust pqcrypto-falcon, Java BouncyCastle) are available on request — email the contact in your application response. If all three verifiers return OK, your hub is technically conformant.

​
Application process

Preferred: self-service form Submit via the public form at https://api.algovoi.co.uk/atb-hubs/apply. The form runs the conformance checks against your keys_url synchronously and stores the transcript with your application. You receive an application ID and can check status at GET /atb-hubs/applications/{application_id}. After submission, AlgoVoi reviews passing applications manually before each monthly registry refresh (typical turnaround 7-14 days). Alternative: GitHub issue
  1. Run the conformance test locally and document the results.
  2. Open an application issue in chopmob-cloud/algovoi-jcs-conformance-vectors titled Hub conformance application: <your hub name>. Include:
    • Hub host (<host>)
    • DID (did:web:<host>)
    • Operator legal name + jurisdiction
    • Methodology version string
    • Public key (PQClean and raw_h formats, base64)
    • Conformance test transcript
    • Operational SLA statement
  3. Review by the AlgoVoi registry maintainer. Typical turnaround 7-14 days.
  4. Inclusion in the next signed registry update (api.algovoi.co.uk/.well-known/atb-hubs.json).
The registry is signed monthly. Mid-cycle additions are possible for security-critical updates (e.g. key rotation), at the maintainer’s discretion.

​
Tiers

TierMeaning
referenceAlgoVoi’s own bench. Canonical implementation of the spec. One per registry.
approvedConformance verified, operational SLA met, sustained presence (>30 days). Default tier for new hubs after initial probation.
provisionalNewly-approved hubs, first 30 days. Distinguishes from established hubs in case verifiers want to apply different trust weight.
Gateways may choose to trust all tiers, or only reference + approved, via per-gateway configuration.

​
Operating outside the registry

The substrate is open. A hub operator does NOT need registry inclusion to issue valid certificates — the gateway operator who wants to trust their certs simply pins them via ATB_PINNED_HUBS_JSON or adds them to ATB_TRUSTED_HUBS. Registry inclusion is a discovery and trust-by-default mechanism. It is not a gatekeeping mechanism. A hub operating outside the registry is operating in good standing under Apache 2.0; gateways trust them on a per-deployment basis.

​
Methodology divergence

A hub MAY operate a methodology with a different scoring formula or threshold from atb-v1.0. The cert envelope makes the methodology explicit (methodology_version field), and verifiers know exactly which scheme produced any given score. Example divergences that are explicitly allowed:
  • Stricter thresholds: a high-assurance hub might require 50 adversarial challenges (vs. AlgoVoi’s 10) before issuing, and a 0.85 pass threshold (vs. 0.70).
  • Domain-specific profile sets: a hub focused on healthcare-domain agents might add HIPAA-relevant profiles and remove unrelated chain-specific ones.
  • Different score weighting: a hub might weight specific OWASP categories higher.
None of these break the substrate. The methodology_version field tells verifiers which scheme is in use; they opt in to schemes they understand.

​
Withdrawal

A hub may withdraw from the registry at any time by emailing the maintainer. The next monthly registry update removes the hub. Live certs already issued continue to verify (the cert envelope is self-contained) until their expires_at time. A hub may be removed by the maintainer for:
  • Conformance test failure on a registry refresh
  • SLA violation
  • Failure to report a key compromise within 24 hours
  • Verified abuse of the registry trust (e.g. issuing certs to known malicious agents)
Removal is logged in the registry doc’s history (signed); the audit trail is permanent.

​
Substrate authorship

The certificate format, the JCS canonicalisation discipline, the Falcon-1024 wire encoding, and the IETF anchor are all AlgoVoi-authored. Hub operators implement the substrate under Apache 2.0; this does not transfer authorship. Compositional positioning (your hub building on the AlgoVoi substrate) is correct and welcome. Substrate-author positioning (your hub claiming authorship of the format) is not.