-02 review: the Verdict binds to a Delivery's identity, not to the evaluation — and `constraints` is committed but discharged by nothing

[msaleme]

You closed PR #10 with "a reviewer who is not its author is the next thing it needs," so
here is one. I read -02 in full and diffed it against -01 rather than working from
Appendix B. Three findings, ranked, plus two smaller ones. All line numbers are from
draft-laxsharma-pact-02.txt.

Thank you also for the acknowledgement on p.79 — I did not expect it, and the place it
ended up (§17.2, and the first sentence of §9.1) is a better home for the observation
than the thread it came from.

First, credit where it is due, because it changes what is worth raising. Three things in
-02 are better built than the field:

• §2's object digest covering "the canonical form of the whole object, including every
  signature member it carries" is the rule that makes the whole chain non-malleable. A
  great many receipt designs hash the payload and leave the signature outside the
  commitment.
• §9.1 making independence a relation the Facilitator derives rather than a field a
  record declares is the correct fix to the self-attestation class, and stating the
  ceiling honestly — "An independence claim reaches exactly as far as the record's own
  commitments" — is rarer than the rule itself.
• typ carrying the full media type, so a signature over one object type cannot stand
  for another.

Everything below sits on top of that, and none of it is a -02 regression. The Verdict's
member set is unchanged from -01 apart from challenge_hash. This is the one layer -02
did not reach.

---

1. The Verdict commits to the instrument and to the results, but never to the pairing

§7.2 already takes the mirror of this seriously:

Without instrument_hash a Verifier could run something other than the committed
instrument and the contract would have no way to tell; that is the substitution attack
of Section 17.4, arriving from the verification side.

That closes the instrument half. The artefact half is open. A Verifier can run the
committed instrument against something that is not work_hash, emit PASS, set
instrument_hash to criteria_hash, and every check in §7.2 passes — because §7.2's
checks are field comparisons, not evidence of execution.

The reason nothing catches it is that results_hash is never constrained. It occurs six
times in the document: lines 685, 708 and 734 (data dictionary) and 1430, 1529 and 1641
(figures). It appears in no normative sentence. Nothing relates it to work_hash, to
input_hash, or to the Delivery's evidence.results_hash. Figures 4 and 5 print them
equal with no rule requiring it.

work_hash is the same: lines 666, 774, 1421, 2251 — dictionary and figures only.
input_hash occurs at 680, 1389 and 1424, and §6 checks only its presence. The Verdict
has no input_hash member at all, so a re-execution Verdict never states what it
re-executed over.

Suggested fix, and it is cheap: require the Verdict to carry work_hash, and
input_hash for tiers that re-execute, copied from the Delivery and compared by the
Facilitator against the delivered entry — the same one-line comparison already applied
to instrument_hash. Challenge.proof has the identical shape and needs the identical
change, otherwise a proof of nonconformance is unbound to the artefact it was computed
over, and the detection mechanism inherits the defect it exists to detect.

2. constraints names a scope restriction that no record discharges

§3.3, line 654:

constraints: object, optional. Tool prohibitions, confidentiality and compliance
conditions, in a form this document does not define.

As a TaskSpec member it occurs twice in 4,424 lines — that dictionary entry and the §2
extension carve-out. No Facilitator check reads it. No Verdict member reports on it. No
conformance vector touches it.

The Verdict's outcome is PASS/FAIL against acceptance, which is a sibling of
constraints in the same TaskSpec. So a contract can prohibit a tool, the Seller can use
it, the acceptance instrument can pass on output shape and thresholds, the Verdict reads
PASS, and the Outcome Record reads FINAL — with every digest verifying.

This is the shape I care about most, and it is general beyond PACT: a scope committed
by hash and discharged by nothing is a commitment to having had an intention. Either
§9's list of what a verification profile states should gain a sixth item covering whether
and how it evaluates constraints and what a Verdict reports about it, or §3.3 should
say plainly that this protocol does not evaluate constraints, so that nobody reads a
PASS as covering tool prohibitions. Silence is the one option that misleads.

3. The Outcome Record carries no verification scope, and outcome.state is lossy

§12 is explicit about the stakes: "It is the input to any reputation system built on
PACT."

Its members (§3.8) do not include task.spec_hash, verification.criteria_hash,
verification.tier, verification.profile, or flow. The verdict trace entry carries
signer but no instrument_hash. So from an Outcome Record alone a stranger learns who
passed the work and not what instrument they ran. Recovering the criteria means fetching
the contract; recovering the TaskSpec means fetching bytes of which §5.2 says "It is
not transmitted over the endpoints of this document", whose spec_uri is optional, and
which §17.12 restricts by default. An Outcome Record can therefore be permanently unresolvable to what was
asked for, by construction.

Separately, Table 2 terminates "FINAL otherwise." Under verdict-first a
verdict-lapsed opens the window with no Verdict, the window closes, no Verdict stands
— FINAL. Under no-window no Verdict is ever accepted — FINAL. So the summary member a
reputation system will key on collapses "verified pass," "nobody checked," and "the
contract forbade checking" into one value. The trace distinguishes them, but the field
named outcome.state does not.

One more in the same family: §3.8 says work_hash "Binds the record to what was
produced" — but §3 opens by stating that no sentence in it requires anything of any
party, and no §12 rule constrains it. Compare terms_result, which gets two arithmetic
invariants and an explicit MUST NOT sign. Of the 26 vectors in Table 3, V-24 covers an
overdrawn transfer and none covers Outcome work_hash. The money is checked; the
artefact is not.

4. Smaller: the Delivery's own evidence.instrument_hash is never compared to criteria_hash

§7.2 requires it of the Verdict. §6's refusal list requires only conformance to the
profile, which §6 defines as "a check on shape, not on substance." So a Seller can ship
evidence naming a different instrument and the Facilitator still records delivered. A
one-line asymmetry — worth closing in §6 or documenting as deliberate.

5. Smaller: §9.1's two normalization rules pull against each other

"the normalization MUST fold toward identifying the same party" versus
"Percent-encoding MUST NOT be decoded." The second defeats the first for any
percent-encoded variant. Where parties.verifier is absent, §14.1.1's kid-attribution
rule does not constrain the signer, because the signer is defined by its own kid. So
a party can hold a key under a percent-encoded variant of its own identifier and satisfy
the independence check. I think the no-decoding argument is right on attack-surface
grounds; the fix is probably to reject an identifier whose decoded form would collide
with a party, or to state the residual risk.

---

On §9.1 more broadly: the rule establishes non-identity of identifiers, and a did:web
host can publish as many DID documents as it likes, so a Seller can register a sibling
identifier and self-verify while passing every check. Your Table 4 wording is careful
about this; §9.1's framing ("Independence is a relation between the party that signs a
Verdict and the parties to the contract") invites the stronger reading. One sentence
saying that independence of control is out of scope would match the honesty of §17.1's
Facilitator row.

Finally — the four defects you found in your own implementation on the second pass
(delivery_hash bypassable, Verdict.instrument_hash and profile never compared,
signing input rebuilt from the parsed header rather than the transmitted bytes,
kid_covers using startswith) are all this same class, and -02 closed each at the
specification level. The three above are the ones that technique will not find, because
they are places where the specification requires no check to exist. An implementation can
conform perfectly and still not detect them.

Happy to be wrong on any of this — particularly on 1, where I may be missing a rule that
binds results_hash somewhere I did not look.

[msaleme]

Correcting my own finding 1 above, which overstated by omission.

I reached it by grepping each hash-bearing member for normative sentences naming that
member. That method misses general rules that apply without naming the field, and §17.5 is
exactly such a rule:

A work_uri, results_uri or any other URI in a record is supplied by a counterparty and
points wherever that counterparty chose. An implementation that fetches it … MUST verify
the sibling hash over the full received bytes before any byte is used for anything. A
fetcher that acts on partial or unverified content has handed its counterparty a way to
make it execute, store or judge something that was never committed to.

I should have cited that in the original comment. It means a compliant Verifier that fetches
the Delivery's work gets the committed bytes or stops, so "a Verifier evaluates the wrong
artefact and violates no MUST" is wrong as written. Withdrawn.

What I think still stands, stated more narrowly.

There is a difference between a digest chain that identifies the intended artefact and a
record that carries evidence the Verifier evaluated it. PACT has the first and not the
second, and §17.5 does not supply it, because it constrains an implementation that fetches
rather than requiring one to:

• work_uri is optional (line 677), so a Delivery need not say where the bytes are.
• §9 leaves "what artefact is evaluated and against what" to the verification profile, not
  to the protocol.
• The Verdict carries no member naming the artefact it evaluated — no work_hash, no
  input_hash — so nothing in the signed record distinguishes a Verdict produced by
  evaluating the Delivery from one produced by evaluating something else, or nothing.

So the gap is narrower than I said and differently shaped: not "the protocol permits
substitution," but "the Verdict makes no checkable claim about which artefact it judged,"
which leaves the property resting on profile text and Verifier honesty rather than on the
record.

And my suggested fix was weaker than I presented it. Adding work_hash and input_hash
to the Verdict would not prove honest execution — a Verifier can copy the digest from the
Delivery without evaluating anything. What it would buy is narrower and still worth having:
it turns an implicit assumption into an explicit, signed, falsifiable claim, so a Verifier
that judged the wrong artefact has to state something false rather than merely stay silent.
That is an attestation, not proof, and I should have said so.

Separately, on constraints (my finding 2). That one is not about artefact binding and
I was wrong to file it alongside. It is a process-compliance question — whether a PASS says
anything about tool prohibitions — and it stands or falls on its own. The §3.3 observation
is unchanged: the member is committed inside spec_hash and no record reports on it, so a
reader cannot tell from an Outcome Record whether the constraint was evaluated. Whether that
should be closed in §9's profile requirements or simply stated in §3.3 is the actual
question, and it is independent of finding 1.

My apologies for the noise. The method error is worth naming for anyone else reading a
specification this way: a grep for normative sentences containing a field name is not a
search for the rules that govern that field.

[msaleme]

Second correction on finding 1, and this one largely closes it.

My previous comment said the Verdict "carries no member naming the artefact it evaluated —
no work_hash, no input_hash." That is true of its direct members and misleading
about the record, because the chain is required and complete:

• §3.5: delivery_hash — "digest, required. Commits to the Delivery judged, including the
  Seller's signature over it."
• §3.4: work_hash — "digest, required. Commits to the delivered bytes, or to a manifest
  per Section 5.1 where the deliverable is a bundle."

So a Verdict transitively and unavoidably commits to the delivered bytes. Combined with
§17.5 on fetching and §5.1 on sibling hashes, a Verdict is a signed, checkable claim of the
form "I judged Delivery D, whose work is W, running instrument I, producing results R,
outcome PASS," with every one of those terms committed.

That is execution evidence in any sense I am entitled to demand. What is missing is
corroboration — nothing lets a third party confirm R was actually produced by running I
over W — but that is a property of essentially every attestation, and holding PACT to it
while calling it a binding gap was me moving the goalposts. A specification is not deficient
because a signer could lie about something it signed.

Finding 1 withdrawn in full. The honest residue is a documentation point at most: the
artefact binding is transitive rather than stated, so a reader checking the Verdict's own
member list does not see it. If anything, a sentence in §7.2 noting that the Delivery
commitment carries the work commitment would save the next reader the walk. That is an
editorial suggestion, not a defect.

I should have caught this myself. My previous comment introduced the rule that a grep for
normative sentences naming a field is not a search for the rules governing it — and then
failed to apply the same discipline to transitive commitments one paragraph later. Twice in
one thread is a method problem, not bad luck, and it is worth naming so the rest of what I
wrote can be weighed accordingly.

What I still think stands, unchanged by this:

• constraints (my finding 2, and it is unrelated to finding 1): committed inside
  spec_hash, and no record reports on whether it was evaluated. A reader of an Outcome
  Record cannot tell whether tool prohibitions were checked. Either §9's profile
  requirements should cover it or §3.3 should say the protocol does not evaluate it.
• The Outcome Record carries no verification scope (finding 3), and outcome.state
  collapses verified-pass, verdict-lapsed and no-window into FINAL, which matters given
  §12 names it "the input to any reputation system built on PACT."
• Findings 4 and 5 (the Delivery's own evidence.instrument_hash never compared to
  criteria_hash; the §9.1 normalization rules pulling against each other) are untouched by
  any of the above.

Apologies for the churn on finding 1. The remaining four are, I hope, worth the noise.

[laxsharma]

@msaleme Highly appreciate reviewing PACT's work, and you read all 79 pages and diffed them against -01. Thank you!

I went through everything against the text and against my own code. You're right on four of the five, and what's left of the first one is still worth a sentence.

On the Verdict and the artefact, I agree with where you ended up. The binding is there, but only if you walk from the Verdict to the Delivery and then on to work_hash, and nobody should have to make that walk to find out the record is sound. I'll add a sentence to 7.2 that just says it.

constraints is the one that stung, and it's worse than you wrote. There's a third mention you didn't count: 18.1 tells people to put their retention and deletion terms in that member. So the draft sends people to a place that nothing ever reads. I'm going to do both of the things you suggested rather than pick one. 3.3 will say plainly that this document evaluates nothing in constraints, and that a PASS is about acceptance and nothing else. And Section 9 gets a sixth thing a verification profile has to state: whether it looks at constraints at all, and if it does, how a Verdict reports on it. "A commitment to having had an intention" is going to stay with me for a while.

The Outcome Record: yes to all three parts. The record already copies parties so it can name its subjects without a fetch, and I can't think of a reason the same logic doesn't apply to task.spec_hash, verification and flow. vtc_hash covers them already, so nothing new gets committed, and a stranger holding only the record can finally see what was checked. outcome will get a member that says whether a Verdict was standing at the end and which one, so a verified pass, a Verifier who never showed up and a flow that never allowed checking stop looking identical. And Section 12 will require work_hash to be copied from the recorded Delivery, with a vector, because you're right that I checked the money and not the artefact.

Finding 4 is a funny one. My Facilitator already refuses a Delivery whose evidence names a different instrument. The text just never says it has to, which is backwards. Section 6's refusal list gets the line.

On normalization, you're right that the two rules fight each other. I still don't want a general decoder in there, and I think there's a way out that doesn't need one. RFC 3986 says a percent-encoded unreserved character is equivalent to the plain one. So any identifier that contains one can simply be refused as not evaluable, which is a pattern match and not a decoder, and the hex digits of every other escape get upper-cased before comparing. did:web's %3A for a port survives because a colon is reserved. You have more aliasing cases in your suite than I've thought of. Does that hold up against them?

And yes on control versus identifiers. 9.1 should say in one sentence that independence here is between identifiers, and that a host publishing sibling identifiers is something this protocol can't see. Table 4 already admits it. 9.1 reads stronger than it should.

I'd like to get all of this into a -03 before the 2 November cutoff. Would you be up for looking at the diff before it posts? And if you'd rather any of it went in as your words than my paraphrase of them, a PR against draft/ is very welcome. Either way the acknowledgements will say what you found.

[msaleme]

First a correction, because you credited me with something I do not have. I have no
identifier-aliasing suite. The harness tests percent-encoding in path traversal and has a
did:web resolution SSRF case, and neither is the thing you are asking. So take what follows
as reasoning about your rule, not as results from a corpus.

Your rule is sound, and it is a profile choice rather than the RFC's operation. Worth
separating those, because §9.1 will read differently depending on which it claims to be.

RFC 3986 §6.2.2.2 establishes the equivalence and recommends decoding percent-encoded
unreserved characters. You are proposing to refuse those inputs instead. It gets there without
a decoder, which is the part I think is right, but it is a stricter profile than the RFC
prescribes, and it will reject identifiers that are well formed and collide with nothing. That
is a defensible trade. It should be stated as one.

On finding 5 specifically, I think it closes it. A verifier that refuses an identifier
carrying an unreserved escape cannot be handed did:web:example%2Ecom as a distinct party, so
the kid-attribution path in §14.1.1 loses that particular variant. I would keep the claim that
narrow: the rule blocks the unreserved-escape form from being accepted. It is not a general
statement about aliasing.

What I would not have it carry is §9.1's sentence above it.

"The normalization MUST fold toward identifying the same party" is a claim about parties.
Normalization is an operation on identifiers. Done well it establishes equivalence or
difference under the rules you specify, which is a real and useful property. What it cannot
establish is that two identifiers which differ under those rules are controlled independently.
Nothing in a normalization rule speaks to who holds them.

That is the gap that matters, it is the same one your Table 4 already admits, and it does not
depend on any aliasing example being real. One controller can hold more than one identifier.
Acceptance rules could constrain which of those a Verifier will honour, but the normalization
is not where that constraint lives.

So my suggestion is the one you already reached for independence of control: make the claim
smaller rather than the rule bigger. Say that the normalization establishes equivalence or
difference of identifiers under these rules, and that independence of control is out of scope.
A reader can then tell what was checked.

Four vectors I would write rather than assert. Host case. Trailing dot. Default port.
Punycode against the U-label. I cannot tell you any of these is a bypass, and I want to be
explicit that I have not shown one: did:web resolution also requires the returned document's
id to match the DID being resolved, which may already close them. They are worth a
conformance vector each, and the vector is what would settle it.

%2541 is the same shape. A single pass sees %25, an escape of %, which is not unreserved,
so this rejection rule alone would not reject it. Whether that matters depends on whether
anything downstream decodes twice, and on whatever other validation you apply. I do not know
that about your implementation and I am not claiming a defect.

On -03. Yes, send me the diff and I will read it before it posts. I would rather do that as
comments on the diff than as a PR against draft/, so the text stays in your voice and the
review stays a review. Same reason I would ask that the acknowledgements describe what was
found rather than name an affiliation. I am reading a public draft as one reader.

[laxsharma]

@msaleme The suite issue, that was me getting two conversations mixed up. The aliasing twins I was thinking of are in the conformance suite behind wowlegend's compliance-fields PR over on x402 (2853), not anything of yours. Sorry about that, I should have fully checked before writing it down.

On the RFC point, fair. 6.2.2.2 says decode those escapes and I'm choosing not to, so it's stricter than 3986 and I shouldn't dress it up as anything else. I'd still rather refuse the escaped form than put a decoder in that path, so I'll write it as my choice and keep the claim to exactly what you said. The escaped form gets refused, nothing about aliasing in general.

You've also talked me out of "fold toward identifying the same party". I liked that sentence when I wrote it, and it promises something a string rule can't keep. What goes in instead is plainer. Normalization tells you whether two identifiers are equivalent under these rules, and whether two different identifiers belong to one controller isn't something this protocol can see. Table 4 already says as much, so 9.1 should stop implying more.

I ran your four vectors through my own normalizer expecting a clean pass, and two weren't. Host case is folded, there's just no vector for it. Trailing dot is the embarrassing one. The text says strip a trailing "/" or ".", and my code does that to the end of the whole identifier, so did:web:seller.example.:agents:etl-3 keeps its dot because the dot isn't at the end. Has to be done on the host. Text change, code change, vector. Default port I simply have no rule for, and both forms survive: https://seller.example:443/ comes out different from the portless one, and so does did:web:seller.example%3A443. 3986 says drop a default port, and for did:web that's just removing the encoded 443 as a string, so no decoder there either.

Punycode turned out to be already answered, sort of. Section 2 says a party identifier is a URI, URIs are ASCII, so a U-label host doesn't parse and falls under the not-evaluable rule. Except my schema pattern accepts anything at all after the scheme, so in practice a U-label sails through today as its own string. Pattern goes to printable ASCII, the text says hosts compare as A-labels, and a vector holds it there.

%2541: nothing on the comparison path decodes, and my Facilitator looks a kid up in a dictionary the harness fills. It never fetches a DID document, so it can't decode twice. What some real resolver's web server does with a path is beyond the record, which is the control point again. I'll still write the vector, for whoever does fetch.

And yes to reading the diff. I'll put -03 up as a draft PR on this repo from a draft-03 branch, with the rendered diff, so you can comment on lines and none of it becomes your text unless you write it. Acknowledgement as before, the finding and the handle you use here, no affiliation. Same as -02.