Wire Format

The PEAC wire format defines the on-the-wire representation of receipts. It is a compact JWS (JSON Web Signature, RFC 7515) with an Ed25519 signature (RFC 8032).

Frozen format

The wire format identifier peac-receipt/0.1 is frozen and will not change until v1.0. New functionality is added through extensions, not wire format changes. This guarantees that any verifier built today will be able to verify receipts issued by any future v0.x release.

Structure

A PEAC receipt is three base64url-encoded segments separated by dots:

Compact JWS Structure

BASE64URL(header) . BASE64URL(payload) . BASE64URL(signature)

Header

The JWS protected header identifies the algorithm, wire format version, and signing key.

JWS Header

{
  "alg": "EdDSA",
  "typ": "peac-receipt/0.1",
  "kid": "<key-id>"
}

Field	Requirement	Value
alg	MUST	EdDSA (Ed25519, RFC 8032)
typ	MUST	peac-receipt/0.1
kid	MUST	Match a key in the issuer's published JWKS

Payload

The payload contains standard JWT claims plus the peac object that carries protocol-specific data.

Receipt Payload

{
  "iss": "https://api.example.com",
  "sub": "agent:consumer-123",
  "aud": "https://verifier.example.com",
  "iat": 1740000000,
  "jti": "rec_a1b2c3d4e5f6",
  "peac": {
    "type": "api.request",
    "attestation_type": "interaction",
    "status": "executed",
    "version": "0.1",
    "extensions": {
      "org.peacprotocol/interaction@0.1": {
        "tool_name": "search"
      }
    }
  }
}

Field	Requirement	Description
iss	Required	Issuer URL -- identifies who issued the receipt
sub	Required	Subject -- identifies the entity the receipt is about
aud	Optional	Audience -- restricts who can verify the receipt
iat	Required	Issued-at timestamp (Unix seconds)
jti	Required	Unique receipt identifier (16--64 characters)
peac.type	Required	Interaction type (e.g., api.request, payment)
peac.attestation_type	Required	Attestation category (e.g., interaction, payment)
peac.status	Required	Lifecycle stage (e.g., proposed, executed, denied)
peac.extensions	Optional	Reverse-DNS namespaced extension data

Signature

The signature is an Ed25519 signature computed over the JWS signing input (<header>.<payload>).

Signing Input

BASE64URL(header) + "." + BASE64URL(payload)

The verifier reconstructs this signing input and checks the signature against the issuer's public key (resolved via the kid from the issuer's JWKS endpoint).

Delivery

HTTP

Receipts are delivered via the PEAC-Receipt response header.

HTTP Response

HTTP/1.1 200 OK
Content-Type: application/json
PEAC-Receipt: eyJhbGciOiJFZERTQSIsInR5cCI6InBlYWMtcmVjZWlwdC8wLjEiLCJraWQiOiJwZWFjLTIwMjYtMDIifQ...

Non-HTTP transports

For MCP, gRPC, WebSocket, and other non-HTTP transports, receipts are included in the response metadata using the transport's native metadata mechanism. The receipt format is identical -- only the delivery channel changes.

Schema

The normative JSON Schema for the receipt payload is maintained in the repository:

Schema Location

specs/wire/peac-receipt-0.1.schema.json

Versioning

Frozen until v1.0

• peac-receipt/0.1 is the current and only wire format version
• No breaking changes will be made to the wire format before v1.0
• New capabilities are added via the peac.extensions mechanism
• At v1.0, the identifier changes to peac-receipt/1.0 and freezes permanently

---

Kernel-First Design

How normative JSON specs drive the implementation.

Receipts

Receipt claims, lifecycle stages, and verification checks.

Conformance Levels

Validate your implementation against 200+ test vectors.