Status: Experimental — v0.1-draft
Website: x428.org
Contact: spec@x428.org

AI agents acting on behalf of human operators routinely access services with legal prerequisites: terms of service acceptance, age-gated content, identity requirements. No standard mechanism exists for agents to attest that these prerequisites have been met — leaving service operators without a defensible record of compliance and agents with no structured way to signal acknowledgment.

x428 fixes that. It extends HTTP 428 ("Precondition Required") semantics into a minimal challenge-response handshake: the server issues a precondition challenge, the client responds with a signed attestation. The result is a cryptographically attributable record that the operator's agent acknowledged a precondition — the agent equivalent of an "I agree" click.

x428 works over plain HTTP, MCP, and A2A. It is a companion to x402 and shares a DID/VC substrate with MCP-I.

Client                                    Server
  |                                          |
  |  GET /api/resource                       |
  |  ---------------------------------------->
  |                                          |
  |  428 Precondition Required               |
  |  X-428-Required: <challenge>             |
  |  <----------------------------------------
  |                                          |
  |  GET /api/resource                       |
  |  X-428-Attestation: <signed-payload>     |
  |  ---------------------------------------->
  |                                          |
  |  200 OK                                  |
  |  X-428-Token: <scoped-token>             |
  |  <----------------------------------------

The challenge names one or more preconditions. The client signs an attestation payload with its operator DID key — binding the attestation to the specific resource, nonce, and precondition IDs in the challenge. The server verifies the signature and issues a scoped token for subsequent requests.

v0.1 defines three types:

TOS ("type": "tos") — Terms of Service. Server specifies a document URL and SHA-256 hash. Client attests the operator has acknowledged that specific document version. Self-attested or VC-backed. Legally equivalent to clickwrap acceptance.

AGE ("type": "age") — Age requirement. Server specifies a minimum age threshold. VC-backed attestations use threshold claims only — no birthdates or exact ages transmitted. Self-attested or VC-backed.

IDENTITY ("type": "identity") — Operator identity anchored to a resolvable DID. v0.1 defines self-attestation only; VC-backed and government-attested tiers are structurally reserved pending identity provider engagement.

x428 creates a cryptographically attributable record that an operator's agent acknowledged a precondition. Self-attestation is operator acknowledgment, not verified fact. Relying parties requiring verified identity or age must require VC-backed attestation. For agent delegation and authorization chains, see MCP-I.

• Canonicalization: JCS (RFC 8785)
• Signatures: Ed25519, mandatory-to-implement
• Operator identity: did:web (production), did:key (development)
• VC proofs: DataIntegrityProof/eddsa-rdfc-2022 or Ed25519Signature2020

spec/
└── x428-draft.md                  # full protocol specification

Reference implementations live in separate repositories:

• x428-protocol/x428-typescript — TypeScript/Node
• x428-protocol/x428-python — Python

v0.1 is a draft specification. The X-428-* headers are non-standard (X- prefix reflects experimental status). Field names and wire format may change before stabilization. Do not build production systems against v0.1 without expecting breaking changes.

Open items before v0.1 is considered feature-complete:

• IDENTITY VC-backed and government-attested tiers (pending identity provider engagement)
• Legal appendix (clickwrap doctrine, operator liability, COPPA, age gating)
• Conformance test vector suite
• Reference implementations

New precondition types can be defined without a wire version bump. See Section 11 of the specification for the companion document requirements — what a type definition must specify to claim x428 compatibility. Open an issue here before publishing a third-party type extension to avoid type string collisions.

• x402 — HTTP-native payments for agents. x428 preconditions must be satisfied before x402 payment challenges are issued.
• MCP-I — Agent delegation and authorization. Complementary layer; operators with MCP-I Level 2+ DIDs can reuse that key material as the x428 operatorId.
• DIF Trusted AI Agents Working Group — Standardization home for MCP-I and related agent identity specs.
• HAP — HTTP Agent Profile. x428 operates above HAP.
• W3C VC Data Model 2.0 — VC attestations must conform to this spec.

Specification: CC BY 4.0 Reference implementations: MIT