Summary

  • The 28 September revision of an individual Canonical Action Identifier Internet-Draft says its digest and canonical form do not change for objects that versions -03 and -04 both accept.
  • The same revision newly refuses some objects with valid -03 CAIDs. An identifier therefore needs its validation-rule and definition context when it is used as evidence across an upgrade.

Imagine an action record whose compact identifier was calculated yesterday and stored next to an approval. Today a verifier receives the record after a software upgrade. The identifier string has not changed; neither has the action object's original content. But the new verifier refuses to process it. An audit system that records only “same ID” or “hash mismatch” cannot explain what happened. The event may be a change in the accepted input set, not corruption of the digest or proof that yesterday's decision was fabricated.

That is the unusually precise news in Iman Schrock's Canonical Action Identifier draft, revision -04, dated 28 September 2026. CAID proposes typed action objects, canonicalization and digest suites, compact identifiers and definitions of which fields count as material for a given action type. Its purpose is to make action identity comparable across artifacts that otherwise choose or encode fields differently. The document is an individual Internet-Draft; the IETF Datatracker says it has no formal standing in the standards process. This article is about a proposal's revision boundary, not a deployed protocol failure or a newly approved RFC.

Section 14 of the revision makes the distinction explicit. It calls -04 a substantive change to the processing model, while saying the suites, digest and canonical form of every object accepted by both -03 and -04 stay the same. That is a narrow continuity promise. It is not a claim that every -03 action remains eligible under -04. The draft itself identifies inputs newly refused, including action objects nested beyond 64 levels, objects whose canonical encoding exceeds 16,777,216 octets, strings containing Unicode noncharacters, and timestamps with lowercase t or z or a leap-second value of 60. Its change log says several of these were action objects whose CAIDs were valid under -03.

There is no need to dramatize an edge case into a known exploit. The point is that a digest and an admission rule answer different questions. The digest binds a canonical representation under a selected suite. The admission rule decides whether an implementation may produce or verify that identifier for the input at all. Tightening the latter can change a verification outcome while leaving the former untouched for the shared set of accepted inputs. A historical verifier's result should remain a historical result under its recorded rules; a current verifier's refusal should remain a current refusal.

Rewriting one into the other would erase the change-control evidence an auditor needs.

The revision also makes a type definition more auditable. It introduces definition_sha256, a digest of the validation projection of an action-type definition, and allows verification to compare against an expected definition digest, reporting definition_mismatch when they differ. That matters because an action type name alone does not prove two parties interpreted the required fields and value sets alike. The author's reference registry moves to version 5 and retains the version 4 file byte-for-byte as history. Those are reference artifacts in a draft, not a claim that IANA has created or deployed the requested registries. They illustrate why a replay needs the applicable definition snapshot as well as the compact CAID string.

Other -04 changes reduce ambiguity at input boundaries: a strict JSON text profile, deterministic refusal ordering and explicit handling of nonconforming definitions. Duplicate JSON member names are among the newly refused cases, including names that differ only in escaping. That example is not the whole story, and later canonicalization cannot repair a parser that has already discarded one of two values. The governance issue here is wider: when an action identifier is intended to bridge authorization, execution and audit records, each participant must know which parsing and definition rules the other used before calling their results compatible.

The draft's mapping profile can yield equivalence under a pinned profile, non-equivalence or an indeterminate result. None of those states turns CAID into authority. The abstract explicitly excludes identity, authorization, execution, safety and legal reliance from the identifier's meaning. A system can agree on the bytes of an action and still disagree about whether the actor was allowed to perform it. This boundary matters, but it is not the revision's central operational change. The central change is that even the eligibility to make the comparison can vary across versions.

An operator assessing a future CAID implementation should therefore ask for a versioned validation receipt alongside an action match: the source object or a verifiable reference to it; the exact identifier and suite; the parser and draft or implementation version; the type-definition digest or pinned registry snapshot; the acceptance or refusal result; and any migration decision. This is Daniel Kade's proposed audit discipline, not a wire field mandated by the Internet-Draft.

It lets a later reviewer distinguish changed rules, changed definitions, changed object bytes and changed trust decisions instead of reducing all four to one green or red badge.

Sources