Skip to content

FEDERATION

Run with the broader C2PA trust ecosystem.

Federate Hashproof with peer registrars over mutual TLS. Trust-list discovery, cascading verification, and selective per-namespace sync, without running your own registry.

What federation gives you

Four properties of every federated session. mTLS by default; cascading verification on demand; selective sync when full union is overkill.

Mutual-TLS peer connections

Each peer registrar exchanges a long-lived mTLS client certificate with Hashproof. All federated traffic flows over authenticated TLS 1.3; no shared API keys, no bearer tokens, no broker.

Cross-registrar trust list

Hashproof maintains a refreshing list of issuer certificates from every federated peer. Verifications match against the union; per-tenant policy decides which peers are trusted.

Cascading verification

When a verify call references a manifest issued by a peer, Hashproof transparently fetches and validates the upstream manifest. Lineage stays intact across registrar boundaries.

Selective sync

Subscribe to specific peer namespaces rather than the full trust graph. Useful when you only need to verify against a sector-specific registrar (newsroom consortium, insurance carrier panel).

How a peer comes online

Federation is configured once. After the initial handshake, verification cascades happen transparently inside ordinary verify calls.

  1. 01

    Configure peer endpoint + certificate

    Submit the peer registrar URL and your mTLS client certificate through the dashboard or POST /v1/federation/peers. Hashproof validates the certificate chain against the C2PA root.

  2. 02

    Federated session is established

    Hashproof opens a long-lived mTLS connection. Trust-list snapshots are exchanged on connect and refreshed on a configurable schedule (default every 6 hours).

  3. 03

    Trust list is unioned in

    The peer registrar is now part of your verification surface. Manifests it issues become known on /v1/verify; cascading verification fetches upstream lineage on demand.

  4. 04

    Tenant policy gates the union

    Per-tenant policy can allow, deny, or rate-limit specific peers. Useful for keeping a sandbox tenant away from production peer registrars during development.

Adding a peer

Federation is enabled per tenant. Once a peer is added, every subsequent /v1/verify call considers its trust list.

curl -X POST https://api.hashproof.ai/v1/federation/peers \
  -H "x-api-key: $HASHPROOF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "https://registrar.example.com",
    "namespace": "newsroom-consortium",
    "clientCertPem": "-----BEGIN CERTIFICATE-----\n..."
  }'

# => {
#   "peerId": "peer_01JS7Z...",
#   "endpoint": "https://registrar.example.com",
#   "trustListSize": 142,
#   "lastSyncedAt": "2026-04-28T17:00:00Z"
# }

Related capabilities

Federation is what turns a single registrar into part of an industry trust graph. It builds on the core verb triple.

Sign

Federation is most valuable when both endpoints sign. Issue C2PA manifests with managed keys, hybrid signatures, and Merkle anchoring.

Verify

Federation extends the verify endpoint across the broader trust ecosystem. One call validates against your registrar plus every peer.

Compliance reports

Reports cite verifications against federated registrars, with per-issuer attribution preserved in the auditor evidence chain.

Federation is on Scale and Enterprise.

Sandbox a peer connection on the Free tier; production federation unlocks at Scale ($299/mo). Enterprise tenants can co-locate registrars.