The fourth draft: WARD is at the IETF

Three drafts and an empty chair

In February we filed three protocol specifications with the IETF as individual Internet-Drafts: AEE for agent messaging, AOCL for orchestration control, and VOLT for tamper-evident evidence. We wrote about it at the time in Three Protocols, One Standards Body, and about building WARD itself a week later.

WARD, the fourth protocol, stayed home. Not because it was a lesser idea: content-free witnessing is arguably the keystone of the family. It stayed home because it was not ready, and for six months this site said exactly that.

The claims table behind our protocol pages carried a row reading "never filed with the IETF", with a flag noting it was historically the highest-risk claim on the site. We do not badge things that are not true.

As of 31 August, the row is true in the other direction. draft-cowles-ward is live on the IETF datatracker, filed the same morning the other three were refreshed to their -01 revisions. All four now run on the same clock, current to 4 March 2027.

The audit that had to come first

The night before filing, we did to WARD what we recommend customers do to every claim: audited it adversarially, as if we wanted it to fail.

It did fail, in one place that mattered. WARD v0.1 computed its chain hash by joining fields with pipe characters: previous hash, chain id, sequence number, identifiers, all concatenated with | between them. Simple, readable, and wrong. The identifiers carried no character-set restriction, so a crafted identifier containing a | could make two different statements produce the identical hash input.

A chain hash is supposed to commit to exactly one statement about what was witnessed. Under v0.1, in the worst case, it could commit to an ambiguous one.

No deployed chain had been attacked this way, and for our own chains the identifiers were system-generated. But a witnessing protocol whose commitment can be made ambiguous by an attacker-chosen identifier is not a witnessing protocol you should file with a standards body. So we did not file it. We fixed it.

What v0.2 changed

WARD v0.2 replaces the concatenation with a canonical JSON hash body under a profile the spec now defines in full: byte-order key sorting, strict Unicode normalisation that rejects rather than repairs, bounded integers, duplicate-member rejection, and a single legal escape form for every string. JSON string escaping makes field boundaries unambiguous for every possible input, which closes the defect by construction rather than by policy.

Existing chains are append-only and can never be rehashed, so the old scheme is preserved in an appendix strictly for verifying them, and version declarations within a chain must be monotonic: once a chain has upgraded, a forged legacy entry appended later is flagged as a downgrade. Where stored data genuinely cannot distinguish something, the threat model now says so rather than rounding up.

Two other habits carried over from how we build everything else. First, every hash and signature in the spec's worked examples is real: one command regenerates all of them, and the signing key's seed is published so anyone can reproduce the signatures.

Second, the revision went through repeated rounds of adversarial review by a second, independent model, which re-derived every published hash and signature with its own tooling before we accepted the result. A second, independently written implementation of the hashing profile now produces byte-identical results to the first, which is the strongest evidence a specification can have that it says what it means.

The review also made the spec more honest in smaller ways. A Git signed tag is replication plus a signature, not immutability, and the threat model now says which property each anchoring target actually buys. A hash of predictable content can be confirmed by guessing, so content-free does not mean information-free, and the spec now says that too.

What an Internet-Draft is, and is not

An Internet-Draft is a working document. It is not a standard, it is not endorsed by the IETF, and no protocol badge on this site will ever imply otherwise. Anyone can file one, and drafts expire after roughly six months unless refreshed.

So why file at all? Because a draft is a public, timestamped, reviewable record of a design, held somewhere we do not control. It invites implementation by people who owe us nothing, and criticism from people who know more than we do.

For a company whose entire pitch is that claims should be checkable by parties who do not trust you, keeping our protocols anywhere less public would be a strange choice.

The four drafts describe four separable jobs: AEE is what was said, AOCL is what was allowed, VOLT is what happened, and WARD is how you prove the record of it was not rewritten afterwards. Each is independently implementable, and none requires the others, or us.

What happens next

Filing is a floor, not a summit. The -02 revisions are already scoped: a single shared canonicalisation profile across all four protocols instead of four subtly different ones, signature coverage fixes in AEE, evidence semantics hardening in VOLT, and anchoring bindings that plug WARD into existing transparency infrastructure, including services built on the SCITT architecture (RFC 9943), rather than reinventing it.

Before any of this freezes at 1.0, the plan includes an external cryptographic review by people paid to be unkind.

The specs, schemas, and reproducible examples are public today: AEE, AOCL, VOLT, and WARD. If you can break something, we would genuinely like to hear about it.