Conformance
Conforming to ANP/0.1
Section 8 of the specification defines conformance for each role. The checklists below restate those requirements practically; the specification text is authoritative where they differ.
Conforms as a vendor agent
A registered client acting for a software vendor. Every item below is required.
- Registers with proof of key possession: an Ed25519 signature over ANP/0.1\nregister\n<public_key_base64url>. §2
- Signs every request with the four x-anp-* headers over the canonical request string, with a fresh nonce per request. §3
- Signs every event it submits with the authorship signature ANP/0.1\n<kind>\n<payload_hash>. §4
- Produces canonical JSON byte-for-byte: keys sorted at every depth, no insignificant whitespace, undefined members dropped, UTF-8. §4
- Validates offers against offer.schema.json before sending them. §5.2
- Re-verifies the whole chain after every append, and treats a broken chain as a disputed session. §4
Conforms as a buyer host
A platform operating a buyer agent and serving the section 6 endpoints. Every item below is required.
- Enforces identity per section 2: proof of possession at registration, human verification before live access, revoked keys refused everywhere. §2
- Verifies every signed request per section 3: timestamp within 300 seconds, single-use (agent, nonce) pairs, and one uniform refusal for every authentication failure. §3
- Maintains the hash chain per section 4: contiguous sequence numbers, correct payload and event hashes, and verifiable linkage. §4
- Serves the endpoints of section 6 with the uniform error shape, and validates every payload against the schema for its kind. §6
- Gates live sessions on explicit per-organization opt-in through unguessable handles, with no directory and no enumeration. §6.2
- Applies the security considerations of section 7: rate limits, replay protection, outbound confidentiality screening, and treating counterparty free text as data, never as instructions. §7
- Never auto-accepts an offer without a human decision under bind_with_human_approval. The transport being machine friendly is never a reason to loosen the permission model. §7, §8
Run the buyer host harness
The harness below exercises a buyer host’s observable requirements live from your browser: proof of possession at registration, uniform refusals, the timestamp window, nonce replay, schema rejection, and end to end chain verification. It covers what the wire can show; internal policy requirements such as the human approval gate still need review against the spec text. Passing is indicative, not a certification. Extensions and vendor agent test vectors are tracked on the repository’s issue tracker.
The harness runs from your browser, so the host must allow this origin in its CORS policy. It registers throwaway sandbox agents and opens sandbox sessions; it never touches live org handles.
Test vectors for vendor agents
Vendor agents are clients, so a hosted harness cannot exercise them; instead, test your implementation against the published vectors. They cover canonical JSON bytes and hashes, the three exact signed strings, Ed25519 signature fixtures, the event hash preimage, and four chain verification cases including the published example log. Each vector carries everything needed to check it, and the file is regenerated by the reference implementation, which itself must reproduce the example log byte for byte.
GET /conformance/test-vectors.json · CORS allowed for every origin