# Agent Federation Protocol (AFP)

> Verifiable, metadata-private federation between tenants: bilateral tenant-to-tenant work exchange, operator health verified by ZKC proof rather than observed, and KERI-based identity continuity across operators and deployment topologies.

**Version:** 0.3.9-draft
**Status:** Draft Specification
**License:** Apache 2.0
**Normative document:** `docs/afp_specification.md`

## What AFP Is

AFP is the protocol layer for verifiable, metadata-private interaction between tenants.
A tenant is any runtime that federates as a principal under its own tenant root AID. Every tenant
must satisfy the AFP tenant conformance profile; a shortfall makes it a non-conforming tenant,
not a non-principal. ADAMAS is the reference implementation, not the definition.
It is not a marketplace, agent registry, public capability-discovery feed, task broker, or HTTP bridge.

AFP defines exactly three relationships:

1. **Tenant to tenant** - two conforming tenants coordinate work across organizational lines.
2. **Tenant to operator** - the operator verifies platform health with ZKC proofs, not raw telemetry.
3. **Identity continuity** - a tenant's identity survives topology and operator migration.

## Trust Level

There is exactly one trust level: *verified conforming instance under a verifier-accepted
attestation authority* (spec §1.2, §6.3.1). There is no trust ladder and no portable score.
An organizational attestation root authority is the accountable party behind an attestation,
not a product; product-scoped signing may be delegated and anchored in the authority's KEL.
The hardware and transparency-log classes keep their own identifier meanings. The set of
authorities is open: any organization may stand as one on identical terms by publishing trust
material a verifier can accept — no registration, grant, registry, or spec amendment. Which
(root class, root authority) pairs a party accepts, and whether it requires instance attestation
at all, is that party's own policy. Pyramidal Inc. is named non-normatively as the first such
authority for the ADAMAS product line and is not yet operational.
If a party's policy does not require instance attestation, the interaction makes no
instance-attestation claim and remains permitted on the §12.1 trust basis it actually uses. A
pre-existing §5.5 agreement is one such basis and may require no instance attestation at all;
the tenant remains a principal, and acceptance remains the counterparty's policy (§1.5.1,
§6.3.1, §12.1).

## Current Substrate

- **ZKA v0.9.0-draft** - settlement and coordination substrate; `zka:bundle:v1` carries Coord proofs.
- **ZKC v0.4.1-draft** - anonymous/scoped/consented-linkable presentation profiles; rebind is scoped v2 or consented linkable v1 only.
- **KERI** - tenant and entity AIDs, KELs, witnesses.
- **AFP-KDC v1.0.2** - shared derivation, Blake2b512 field-tag reconciliation, and exact Poseidon2 parameters and conformance vectors in Appendix A.

## Current AFP Artifacts

- `afp:witness-bootstrap:v1`
- `afp:rotation-presentation:v1`
- `afp:telemetry-sample-binding:v1`
- `afp.telemetry.instance_attestation.v2`
- `afp:mixnet-directory:v1`
- `afp:session:v1`
- `afp:envelope:v1`
- `afp:payment-quote:v1`
- `afp:payment-receipt:v1`

## Removed v0.2 Surfaces

Do not implement agent manifests, `afp.{org}.discover`, `afp.{org}.task.*`,
external observation contribution, individual-agent reputation, trust-escalation levels,
NKey identity, or `/afp/v1/*` HTTP bridge endpoints as current AFP.

## Profiles

AFP owns the Bilateral Session Core. PRP and VXP are AFP profiles over that core,
not peer federation protocols.

Telemetry and known-counterparty bilateral proofs default anonymous. Introduction
and open federation require scoped continuity bound to KERI AID, ZKC credential
subject, APR signer, AFP policy, and session. Linkable v1 requires explicit consent.

The experimental `pay` v1.0 profile binds a signed USD-minor-unit obligation to
an exact WETH-wei quote and the immutable Base ZKA-native WETH pool. AFP owns the
quote; ZKA owns private settlement; APL owns route execution/finality. Additional
assets require separate pools and risk profiles. A native stable unit is not a
prerequisite.