WAB for Email — verifiable agent metadata in email headers

Headers

Header	Required	Value
`X-WAB-Manifest`	required	Absolute URL to the sender's `/.well-known/wab.json`
`X-WAB-Action`	optional	Action id from the manifest this email relates to (e.g. `order.confirmed`)
`X-WAB-Receipt`	optional	Signed ATP receipt (base64 JWS) for the action — see ATP semantics
`X-WAB-Signature`	optional	`ed25519=<base64>` over `SHA256(Date + From + To + Subject + Message-ID)`

Example email

From: orders@example-shop.com
To: alice@example.com
Subject: Order #1842 confirmed
Date: Mon, 25 May 2026 17:20:00 +0000
Message-ID: <1842@example-shop.com>
X-WAB-Manifest: https://example-shop.com/.well-known/wab.json
X-WAB-Action: order.confirmed
X-WAB-Receipt: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJob3N0…
X-WAB-Signature: ed25519=Bx9k7q…
Content-Type: text/html; charset=utf-8

…

Verification flow (receiving agent)

Read X-WAB-Manifest and fetch the manifest URL (cache 5 min).
Confirm the From domain matches the manifest's host field.
Look up the manifest's signing key from DNS _wab.<host> TXT (pk=ed25519:<b64>).
Verify X-WAB-Signature over the canonical header digest using that key.
If X-WAB-Receipt is present, decode the JWS and confirm the action id matches X-WAB-Action.

Why not just DKIM/ARC?

DKIM proves the domain authorised the message; WAB headers prove what action the message represents.
An agent inbox can route, summarize, or auto-acknowledge based on the action id alone.
ATP receipts in email give end-users a verifiable record of every transaction without storing PII on the sender side.

Status

Draft 0.2 — implemented by the reference server in web-agent-bridge (server/services/email.js). Feedback welcome via responsible disclosure or GitHub issues.