Registries

PEAC Protocol maintains registries for extension groups, receipt types, and advisory classifications. These registries define the standard vocabularies that all implementations use to describe interactions, payments, and other protocol events.

Extension Groups (Wire 0.2)

Wire 0.2 defines 12 typed extension groups under the extensions field, keyed by reverse-DNS. Known groups are schema-validated during verification; unrecognized-but-well-formed keys are preserved with a warning. Registered first-party evidence types require their mapped extension group in strict mode; interop mode downgrades to warnings.

Wire 0.2 Extension Example

{
  "extensions": {
    "org.peacprotocol/commerce": {
      "payment_rail": "x402",
      "amount_minor": "10000",
      "currency": "USD"
    },
    "com.example/custom-data": {
      "custom_field": "value"
    }
  }
}

Registered extension groups

Key	Fields	Description	Status
org.peacprotocol/commerce	payment_rail, amount_minor, currency, reference?, asset?, env?	Payment evidence	Stable
org.peacprotocol/access	resource, action, decision (allow/deny/review)	Access control decisions	Stable
org.peacprotocol/challenge	challenge_type, problem (RFC 9457), resource?, action?, requirements?	Challenge requirements	Stable
org.peacprotocol/identity	proof_ref?	Identity attestation	Stable
org.peacprotocol/correlation	trace_id?, span_id?, workflow_id?, parent_jti?, depends_on?	Workflow correlation	Stable

Third-party extensions

Third-party extensions use reverse-DNS keys under their own domain (e.g., com.example/custom-data). No registration is required: the namespace itself prevents collisions. Extension keys follow the grammar <domain>/<segment> where domain contains at least one dot and segment is [a-z0-9][a-z0-9_-]*.

Receipt Types (Wire 0.2)

Wire 0.2 receipts have a required type field using reverse-DNS or absolute URI format. The protocol defines 10 recommended types, one per pillar:

Type	Pillar	Extension Group	Description
org.peacprotocol/payment	commerce	org.peacprotocol/commerce	Payment evidence
org.peacprotocol/access-decision	access	org.peacprotocol/access	Access control decisions
org.peacprotocol/identity-attestation	identity	org.peacprotocol/identity	Identity attestation
org.peacprotocol/consent-record	consent	(type-only)	Consent records
org.peacprotocol/compliance-check	compliance	(type-only)	Compliance checks
org.peacprotocol/privacy-signal	privacy	(type-only)	Privacy signals
org.peacprotocol/safety-review	safety	(type-only)	Safety reviews
org.peacprotocol/provenance-record	provenance	(type-only)	Provenance records
org.peacprotocol/attribution-event	attribution	(type-only)	Attribution events
org.peacprotocol/purpose-declaration	purpose	(type-only)	Purpose declarations

Custom types

Custom types are fully supported. Use reverse-DNS format (e.g., com.example/custom-flow) or absolute URI. Unregistered types are accepted during verification with a type_unregistered advisory warning.

Kind Semantics (Wire 0.2)

Wire 0.2 receipts have a required kind field with two structural values:

Kind	Meaning	occurred_at
evidence	Records something that happened	Allowed
challenge	Declares what is required before proceeding	Not allowed

Pillar Taxonomy (Wire 0.2)

The optional pillars field uses values from a closed 10-pillar taxonomy. Values must be sorted and unique.

Pillar	Description
access	Access control and authorization
attribution	Source attribution and citation
commerce	Payment and commerce evidence
compliance	Regulatory compliance checks
consent	Consent and terms acceptance
identity	Agent identity attestation
privacy	Privacy signal observation
provenance	Content provenance tracking
purpose	Purpose-based access control
safety	Safety review and assessment

Wire 0.1 Claims

Wire 0.1 uses flat payload claims. These are unchanged and stable.

Claim	Description
iss	Issuer URL
aud	Audience URL
iat	Issued-at timestamp
amt	Payment amount
cur	Currency code
rail	Payment rail identifier
reference	Transaction reference
subject	Subject resource URL

Protocol registries

The specs/kernel/registries.json file also defines registries for payment rails, control engines, transport methods, and agent protocols:

Registry	Contents
payment_rails	x402, L402, card-network, UPI, Razorpay
control_engines	Spend control, risk engine, mandate service, TAP, RSL
transport_methods	DPoP, HTTP message signatures, none
agent_protocols	MCP, ACP, AP2 (Google), TAP (Visa)
receipt_types	10 pillar-recommended receipt types (Wire 0.2)
extension_groups	5 core extension groups (Wire 0.2)

Advisory registries

Advisory registries define informational vocabularies. Unlike extension groups, advisory registry values are not enforced at the schema level: they provide standard terminology that implementations should use for interoperability.

toolcall_op_types

Types of tool call operations.

Type	Description
read	Read-only data access
write	Data modification
execute	Command execution
query	Search or query operation
subscribe	Event subscription

toolcall_resource_types

Types of resources accessed by tool calls.

Type	Description
api	REST or GraphQL API endpoint
database	Database query or mutation
file	File system access
network	Network resource
compute	Compute resource

Normative specification

The normative registry definitions are maintained in:

Registry Spec Location

specs/kernel/registries.json

Adding to registries

First-party extension groups and receipt types are registered by submitting a pull request to the PEAC Protocol repository. Advisory registries are informational and can be extended without breaking changes. Third-party extension keys do not require registration.