[SCITT] Re: draft-noa-scitt-ai-agent-receipt-00 - ARP reconciliation run against the EMILIA and Noa corpora

[Joel Hillier <[e-mail]>]

Hey everyone,

This is the run I said I would do: ARP against the published vectors rather
than another round of argument. It is long because the numbers are the point.
Pinned commits below, harness attached, so anyone can reproduce or contradict any figure in it.

  emiliaprotocol/emilia-protocol  125e4f4311f1319fef3f6d55c935c9ea4da5fc1b
  NordenSoft/noa                  21eadb38ae494cbeb64d7773486ed7c4a8417754

Real Ed25519 verification was performed on EP-RECEIPT-v1 and EP-BOUNDARY-v1, including full EP-MERKLE-v2 anchor reconstruction, and on the Noa receipt chain (chain-hash recompute plus signature against the published keyring).

The WebAuthn, RFC 3161, TSA-renewal and sparse-Merkle suites are consumed as declared and are labelled that way in every row of the output, so the totals cannot be read as more than was done.


1. ARP's shared subject digest interoperates exactly

ARP-01 Appendix D pins the correlation key: subject_digest =
SHA-256(JCS(action)). Measured against the 22 EP-CANONICALIZATION-v1 vectors carrying a pinned digest and a parseable input:

  Appendix D  SHA-256(JCS(action))   agrees with EP:  22 / 22

Appendix D's premise, that capsules produced by parties with no shared
producers and no shared schemas correlate on a common digest, now holds
against a deployed corpus rather than only on the page. That is the property
the whole composition rests on, and it is the one nobody had measured.

Anton, this also settles the CPB Related Work question in your favour. Your
text concerns Section 2's Canonical Claim rules, explicitly not Appendix D's
subject digest, and that distinction is exactly right. Use the wording as
drafted.


2. The refinement -02 will carry

ARP-01 defines a second construction for a different purpose: the Section 2
Canonical Claim, whose hash indexes the Settlement-Layer Ledger. It applies
Unicode NFC by design. JCS does not. Against the same 22 vectors it agrees
20/22 under a UTF-16 member sort and 19/22 under a code-point sort.

That divergence is intentional at the ledger layer. Folding NFC and NFD
spellings of the same claim to one index is the behaviour you want when the
question is "have I seen this claim before". It is not the behaviour you want
on a correlation key, and the two divergences are collisions rather than
mismatches:

  accept_nfd_decomposed  EP pins a959c355  S2 computes a84c1745
  accept_angstrom_sign_not_normalized  EP pins f560f24d  S2 computes 08eb5b93

a84c1745... is byte-for-byte EP's pinned digest for accept_nfc_composed.

So -02 will state normatively that the Claim Hash and the subject digest are
distinct constructions serving distinct purposes and MUST NOT be substituted for one another, pin the Section 2 member-sort code unit, and carry an explicit construction identifier so a consumer can determine compatibility rather than assume it. The harness emits identifiers whose digests commit to the declared canonicalization parameters:

  arp-subject-digest/1   id=f23ecefd99c54182  App.D, SHA-256(JCS(action))
  arp-canonical-claim/1  id=7d90aa1cbee90ef9  S2 Canonical Claim (NFC applied)
  ep-canonicalization/1  id=dc7df29214870f78  EMILIA EP-CANONICALIZATION-v1

Iman, looking forward to talking later this week. This is the empirical
answer to your guardrail, and it lands on your side. You asked that a CAID
mapping hold only where canonical fields, serialization, digest algorithm and
domain context match exactly, and fail closed otherwise. On the correlation
key they match exactly, 22 out of 22. On the ledger construction they do not,
and the difference is invisible without a shared vector. Fail-closed is
correct precisely because of that.


3. The interop set: the signature verifies and ARP still refuses

frozen-v1 publishes five EP-BOUNDARY-v1 vectors, covering four of the six
behaviours. With signatures actually verified rather than assumed:

  accept_pre_execution_receipt
      INDETERMINATE
  attribution_substituted_for_authorization
      REFUSE   attribution-substituted-for-authorization
  raw_claim_pass_through
      REFUSE   raw-claim-not-covered-by-signature
  same_party_evidence_presented_as_independent
      REFUSE   agent-impersonation-suspected
  policy_decision_presented_as_human_authorization
      REFUSE   machine-decision-not-human-authorization

In rows two and five the Ed25519 signature is genuine, verified here against
the vector's own key, and ARP refuses on the artifact-class leg. Attribution
states who was recorded as executing; it never grants authority. Machine
policy allowed is never named human approved. A verifier that returns one
boolean cannot express "signature good, claim wrong", which is the failure
mode this thread exists to design out.

The control does not approve either. accept_pre_execution_receipt is held at
INDETERMINATE with caid-binding-unverified, because its action_digest comes from a construction ARP has not been given a vector for. That is the
guardrail applied to the positive case, not only the negative ones. Publish
the action_digest preimage rule and that row upgrades to APPROVE on the next run.

Two of the six behaviours, controller-reported outcome and
physical-completion non-claim, have no vector in frozen-v1. ARP implements
both predicates. I will contribute the two vectors unless someone is already
drafting them.


4. Noa: the failures no per-receipt verifier can reach

23 of 23 adversarial files produced at least one integrity-class divergence
axis. The interesting part is which legs fire:

  cross-chain-splice   chain-scope-mismatch, chain-sequence-duplicate,
                       chain-head-truncated
  seq-gap              chain-sequence-gap, chain-link-broken
  tail-truncated       chain-head-truncated
  relinked             chain-link-broken
  tampered-content     artifact-tampered, signature-invalid

cross-chain-splice is the clean demonstration: both of its receipts hash
correctly and verify correctly in isolation. The forgery is a property of the
set, and it is only nameable at a layer that reconciles across sources. That
is the argument for a reconcile leg, made against someone else's attack
corpus.

The valid chain also produces the cleanest three-way authorization result in
the run. Three cryptographically indistinguishable receipts:

  seq 0   DEFERRED, no approval                -> agent-credential-absent
  seq 1   EXECUTED, approval.by = HUMAN:...    -> match
  seq 2   EXECUTED, low-risk-auto, no approval -> human-authorization-
                                                  unproven

Tora, your draft is explicit that a receipt attests tamper-evidence and not
correctness. This is that scope boundary rendered as a machine-checkable
field instead of a caveat in prose. No rush before the 15th.


5. Axis alignment: five of these are already filed

95 reject_* identifiers across the 16 EMILIA suites, all 95 mapping to a
named ARP divergence axis. The structural point is better than a new
vocabulary: five of the axes the corpus exercises are already normative in
filed text.

  agent-action-scope-divergence   ARP-01 S4, A.4
  agent-impersonation-suspected   ARP-01 S4, S6.3
  agent-principal-unverifiable    ARP-01 S4
  agent-credential-absent         ARP-01 S4
  freshness-stale                 ARP-00 S6

So the alignment is mostly confirmation rather than negotiation. The genuine
proposals are in the write-up, in the same kebab-case convention.

Worth noting that this run also puts a test behind a filed normative MUST.
ARP-01 S3.2 and S6.3 require friend-or-foe determination to default to ENEMY
and say the server MUST NOT silently upgrade an ENEMY requester to FRIENDLY.
The harness enforces the same discipline one layer over, at the artifact
level: an unproven binding is held at INDETERMINATE and never upgraded,
including on the positive control. The self-check asserts it. No case
APPROVEd while carrying an unproven binding.

Three names worth arguing rather than assuming:

  - agent-credential-absent covers both "no authorising credential exists"
    and "a required signoff is missing". One axis or two?

  - version-replay covers both "unsupported format version" and "legacy
    anchor refused by default". One axis or two?

  - canonicalization-gate-failed covers parse-boundary failures, I-JSON
    profile-predicate failures, and representation-canonicality failures
    such as a timestamp without an offset. One axis or three?

And one proposed new axis, anchor-leaf-not-bound-to-payload: a valid
inclusion proof for a leaf that is not this receipt's payload is a different
failure from a broken proof. The corpus has no vector isolating it, so I am
arguing the distinction rather than demonstrating it. A vector that is
unbound but otherwise proof-valid would settle it.


6. Coverage of the run

Stated precisely so every figure above can be quoted without qualification.
Parse-boundary checks are Noa's, not this harness's: Python's json.loads
accepts duplicate member names and lone surrogates where Noa rejects them at the parse boundary, so seven of the nine malformed/* files are refused at the shape gate rather than by a purpose-built parse check. The verdict is correct in every case.

Of the 129 EMILIA cases outside the canonicalization suite, 18 were verified cryptographically here and 111 were consumed as declared; WebAuthn, RFC 3161, TSA renewal chains and sparse-Merkle proofs are the producer's verification surface, not the reconciliation layer's, and are included so the axis vocabulary can be aligned across all 16 suites. On reject_v2_unbound_leaf and reject_legacy_v1_anchor_by_default the run refuses at the leaf-binding and algorithm gates and does not go on to evaluate the proof.

One ask: Steven, Tom, Songbo, I would like a copy of "Agent Accountability:
Composition and Conformance" (5 July). ARP-01 Appendix D composes over the CAN / WHO / WHAT / AUDIT slots and should cite it normatively in -02 rather than describe it.

Attached: the harness, the console output, the machine-readable JSON, and the write-up with the full axis table.

Best regards,

Joel Hillier PhD MBA
Chief Executive Officer and Founder
Certisyn, Inc.

https://certisyn.com
https://datatracker.ietf.org/doc/draft-hillier-scitt-arp/