PEAC Working Group
Open Specification
Status: Working Draft
Version: 0.9.23
Wire Format: peac.receipt/0.9
December 2025

PEAC: Policy-backed Environment for Agent Coordination

A protocol for cryptographic receipts proving policy compliance, payment, and attribution in machine-to-machine interactions.

Abstract

This document specifies the PEAC Protocol, an open standard for issuing and verifying cryptographic receipts that prove policy compliance in AI agent interactions, API access, and data consumption.

PEAC receipts are Ed25519-signed JSON Web Signatures (JWS) that encode claims about access permissions, payment status, attribution requirements, and regulatory compliance. The protocol defines discovery via well-known policy files, negotiation flows, and receipt verification procedures.

Status of This Document

This is a working draft. The wire format peac.receipt/0.9 is frozen across the v0.9.x series. Breaking changes will only occur in v1.0, which requires multi-implementation consensus.

Table of Contents

1. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Receipt
A cryptographically signed attestation of a completed transaction or policy evaluation.
Issuer
The entity that creates and signs receipts. Identified by the iss claim.
Verifier
Any party that validates receipt signatures and claims.
Policy
A machine-readable declaration of access terms, published at /.well-known/peac.txt.
PaymentEvidence
Structured proof of payment including rail, amount, currency, and optional facilitator.
Attestation
A generic third-party claim attached to a receipt (e.g., risk assessment, compliance check).

2. Wire Format

PEAC receipts are encoded as JWS Compact Serialization (RFC 7515) with detached payload option available. The receipt MUST be transmitted via the PEAC-Receipt HTTP header.

PEAC-Receipt: <base64url(header)>.<base64url(payload)>.<base64url(signature)>

Header (REQUIRED):
{
  "alg": "EdDSA",           // MUST be EdDSA
  "typ": "peac.receipt/0.9", // MUST be this value
  "kid": "peac-2025-12"      // Key identifier
}

Payload (REQUIRED fields):
{
  "iat": 1735500000,         // Unix timestamp (seconds)
  "iss": "https://api.example.com",
  "amt": 100,                // Amount in minor units
  "cur": "USD",              // ISO 4217 currency
  "payment": {               // Payment evidence
    "rail": "x402",
    "facilitator": "daydreams"
  }
}

Wire Schema (v0.9.21+)

JSON Schema definitions are available at specs/wire/ with Ajv 2020-12 validation and conformance fixtures.

3. Policy Discovery

Agents MUST attempt to fetch policy from these locations in order:

  1. /.well-known/peac.txt (primary)
  2. /peac.txt (fallback)

The policy file uses YAML format with the following structure:

version: "peac-policy/0.1"
rules:
  - id: allow-licensed
    match:
      subject_type: [agent, organization]
      purpose: [train, inference]
      licensing_mode: licensed
    decision: allow
    receipts: required

  - id: allow-crawl
    match:
      purpose: [crawl, index, search]
    decision: allow

  - id: deny-unlicensed-training
    match:
      purpose: [train]
      licensing_mode: unlicensed
    decision: deny

4. Receipt Structure

ClaimTypeStatusDescription
iatnumberREQUIREDIssued-at timestamp (Unix seconds)
issstringREQUIREDIssuer URI
amtnumberRECOMMENDEDAmount in minor units (cents)
curstringRECOMMENDEDISO 4217 currency code
paymentPaymentEvidenceOPTIONALPayment evidence with rail and facilitator
attestationsAttestation[]OPTIONALThird-party attestations (v0.9.21+)
extensionsExtensionsOPTIONALNamespaced extension fields (v0.9.21+)
provobjectOPTIONALProvenance metadata (C2PA, etc.)
audstringOPTIONALIntended audience

5. Verification Procedure

Verifiers MUST perform these steps in order:

  1. Parse JWS: Decode base64url header and payload. Reject malformed tokens.
  2. Validate header: Confirm alg is “EdDSA” and typ is “peac.receipt/0.9”.
  3. Fetch JWKS: Retrieve public key from issuer's /.well-known/jwks.json matching kid.
  4. Verify signature: Validate Ed25519 signature over header.payload.
  5. Check timestamp: Reject if iat differs from current time by more than 5 minutes.
  6. Validate evidence: Ensure payment.evidence contains only JSON-safe values (no NaN, Infinity, cycles).

6. Conformance Levels

L0Discovery
  • -Parse /.well-known/peac.txt
  • -Understand version field
  • -Honor usage directive
L1HTTP
  • -Return proper status codes
  • -Use Problem Details (RFC 9457)
  • -Include PEAC-Receipt header
L2Policy
  • -Enforce rate limits
  • -Validate purposes
  • -Check attribution requirements
L3Commerce
  • -Support HTTP 402 flow
  • -Issue valid receipts
  • -Verify payment evidence

Conformance Harness (v0.9.21+)

The protocol includes a conformance test suite with valid, invalid, and edge-case fixtures. See specs/wire/ for the JSON Schema definitions and test vectors.

7. Evidence & Attestations

PEAC v0.9.21 introduces generic Attestation and Extensions types for extensible evidence attachment.

Attestation Structure
{
  "attestations": [{
    "type": "risk_assessment",
    "issued_at": 1735500000,
    "issuer": "https://risk.example.com",
    "data": {
      "score": 0.95,
      "level": "low"
    }
  }],
  "extensions": {
    "acme/tracking_id": "abc123",
    "vendor/metadata": { "key": "value" }
  }
}

Evidence Validation

All evidence fields MUST contain JSON-safe values only. The protocol rejects NaN, Infinity, object cycles, and class instances at issuance time. DoS caps apply: maxDepth (32), maxArrayLength (10k), maxObjectKeys (1k), maxStringLength (64KB), maxTotalNodes (100k).

8. Security Considerations

Key Management

Issuers MUST rotate keys regularly. The kid field enables graceful key rotation. Old keys SHOULD remain in JWKS for verification of existing receipts.

Replay Protection

Verifiers SHOULD implement nonce tracking or timestamp windows to prevent receipt replay attacks. TAP (Trusted Agent Protocol) enforces an 8-minute maximum time window.

JWKS Fetch Security

JWKS endpoints MUST be served over HTTPS. Verifiers MUST validate TLS certificates and SHOULD implement SSRF protections including literal IP blocking.

Fail-Closed Defaults

ISSUER_ALLOWLIST is REQUIRED (500 if empty). Unknown TAP tags are rejected by default. Replay protection is required when nonce is present.

9. Telemetry & Observability

PEAC v0.9.22 introduces telemetry hooks in the issue() and verify() functions with privacy-preserving modes.

Strict Mode

Hash all identifiers. Requires hashSalt. Maximum privacy.

Balanced Mode

Include rail + amounts. Hash sensitive fields. Recommended default.

Custom Mode

Allowlist-based field inclusion. Full control over what is emitted.

OpenTelemetry Integration
import { createOtelProvider } from '@peac/telemetry-otel'

const provider = createOtelProvider({
  tracer,
  meter,
  privacyMode: 'balanced'
})

// Automatically emits spans and metrics
const { jws } = await issue({ ...claims, telemetry: provider })

10. Normative References