content_marking.verify_assertion accepts missing required binding fields when both sides omit them

[altrudev]

Problem

On current main at a247244fb0bb97aea4e60d655f36d445cca18cd5, content_marking.verify_assertion() checks the duplicated binding fields with ordinary .get() equality:

if record.get("subject") != data.get("subject"):
    raise RecordMismatch(...)

if record.get("eat_profile") != data.get("eat_profile"):
    raise RecordMismatch(...)

That establishes equality only when at least one side has a value. It does not establish presence.

If a peer-produced assertion omits data.subject, and the hash-matching fetched record also omits subject, both reads produce None, so the comparison passes. The same is true for eat_profile.

A malformed assertion and malformed referenced record can therefore agree by mutual absence and verify_assertion() returns the parsed record successfully.

Why this is a contract violation

spec/content-marking-v1.md section 2 marks both fields as required:

Field	Required
subject	yes
eat_profile	yes

The verification algorithm then requires the consumer to check that both assertion fields match the fetched record, and section 6 says a conforming consumer performs those checks.

The module's own public contract says malformed assertions raise ContentMarkingError. Mutual absence is malformed input, not a successful binding.

This matters independently of full TRACE-record verification. verify_assertion() explicitly performs only the content-marking binding check and returns the parsed record on success. A caller is allowed to run this layer separately from the later Trust Record signature/schema verification, so this layer has to establish its own required assertion shape rather than relying on another verifier to reject the fetched record later.

Minimal reproduction

Conceptually:

1. Start from a valid assertion/record pair.
2. Remove subject from both the assertion data object and the referenced record.
3. Recompute record.hash over the exact modified record bytes.
4. Call verify_assertion(assertion, modified_record_bytes).

The hash check succeeds because it is over the modified bytes. The subject comparison becomes:

None != None  # False

and therefore does not reject.

Repeat with eat_profile; the same thing happens.

A stronger regression matrix should include:

• assertion missing subject, record missing subject;
• assertion missing eat_profile, record missing eat_profile;
• both fields missing on both sides;
• assertion-only omission still refused;
• record-only omission still refused;
• valid pair still succeeds.

The first three are the cases current equality cannot distinguish.

Bounded fix direction

Establish the assertion's required fields before comparing them to the fetched record. For example, require:

• data.subject to be a valid non-empty SPIFFE URI or DID string;
• data.eat_profile to be a non-empty string;
• corresponding fetched-record fields to be present with the expected shape before equality is evaluated.

Then use RecordMismatch only for two present, individually valid fields that disagree. Missing/malformed fields should remain ContentMarkingError, because that means malformed content rather than a well-formed assertion pointing at a different record.

No digest algorithm, C2PA manifest-signature, TRACE signature, URL, anchor, or wire-format semantics need to change.

Adjacent producer-side observation

build_assertion() already validates the record subject shape, but its eat_profile guard is only:

if not profile:
    raise ContentMarkingError(...)

so a truthy non-string eat_profile can be copied into a produced assertion. That is adjacent evidence that these two required binding fields do not yet have one shared shape boundary, but it is not necessary to fix the mutual-absence verifier defect and should not broaden this issue unless maintainers prefer to consolidate the field-validation contract.

Duplicate / ownership review

I searched issues and PRs for content_marking, verify_assertion, missing/required subject, and eat_profile. I found no existing issue or PR covering this mutual-absence success case.

PR #227 is adjacent but different: it fixed non-object / invalid-JSON record_bytes crashes. PR #325 sweeps malformed public-function arguments and several parameter-shape failures, but it does not validate nested required members inside a content-marking assertion.

AI-assistance disclosure: ChatGPT assisted with current-main source review, spec comparison, duplicate/ownership search, reproduction design, and issue drafting. altrudev reviewed the bounded claim and remains responsible for the contribution.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[lywinged]

Confirmed on a247244, and the duplicate question answered against #325's branch rather than its description.

It reproduces, and the boundary is exactly where you put it. Your matrix run as six cases, with record.hash recomputed over the modified bytes each time so the pair stays self-consistent:

ACCEPTED                 subject absent on both sides
ACCEPTED                 eat_profile absent on both sides
ACCEPTED                 both fields absent on both sides
refused(RecordMismatch)  assertion-only omission
refused(RecordMismatch)  record-only omission
ACCEPTED                 valid pair

The first three are the cases equality cannot distinguish, as you said. The two single-side controls are what make that precise rather than merely true: the hole is mutual absence and not something wider, and verify_assertion returns the parsed record on all three.

Not a duplicate of #325, checked on its head. At 3434601:

• The same six cases give the same six results, so the defect is untouched.
• All 16 lines that PR adds to content_marking.py are inside build_assertion: the alg type guard, the anchor guard, and a docstring. Nothing is added to verify_assertion, and the three added lines that mention it are all in the PR's test file.
• test: sweep every keyword argument of every public function, and close what it found #325's suite is green on that head, 1494 passed, 1 skipped, 2 xfailed, with this defect present.

That last line is the sharper half: the sweep does not merely lack the fix, it cannot see the defect. That is not for want of covering the function. It varies both of verify_assertion's parameters against the junk matrix, assertion positionally through CALLS and record_bytes through KEYWORD_CALLS, carries witnesses for it in both KEYWORD_REACHES and REACHES, and calls it once more as the verifier in the producer round trip for build_assertion. What none of that reaches is this input. Both baselines carry subject and eat_profile, and _ASSERTION is built from _RECORD_JSON so it carries them too, while substituting a parameter replaces the assertion or the record outright. Nothing in that shape removes a nested member from both sides with the hash recomputed to match. Parameter level and member level are different layers, which is the distinction you drew and it holds.

No other open pull request touches content_marking.py or verify_assertion: checked 313, 315, 318, 322, 323 and 325, which is the whole open set.

One coordination note, not an objection. If the fix takes up your adjacent producer-side observation and tightens build_assertion's eat_profile guard, that guard is at line 161 on #325's head while #325's two new guards are at 135 and 141, in the same function. Merge order matters there and nowhere else in this issue. Leaving it out, as you proposed, keeps the two independent.

Tool-assisted: the runs and this write-up.

---

Generated by Claude Code

[imran-siddique]

Confirmed, fixed in #335, and @lywinged's six-case run reproduces exactly here at 0aefa1f.

You were right that this is about presence rather than agreement, and right that it cannot be deferred to a later verifier. verify_assertion returns the parsed record before any Trust Record signature or schema check runs, and a caller is allowed to run this layer alone, so it has to establish its own required shape. Section 2 marks both fields required and section 6 puts the check on the consumer.

The part that took a decision was which exception belongs on each side, and this file had already answered it. test_an_int_no_longer_reports_a_record_mismatch says RecordMismatch means the URL is serving something else, and reporting it for a caller's own malformed input points the reader at the wrong party. So:

• an assertion missing a required field is ContentMarkingError, since the malformed input is the caller's
• a record missing one is RecordMismatch, since it matched the declared hash and that URL really is serving something that is not a conformant record
• two present values that disagree are unchanged

That moves the assertion-side omission from RecordMismatch to its ContentMarkingError parent. Nothing catching the documented contract loses, and anything catching RecordMismatch specifically was being told the wrong party was at fault.

@lywinged, your two single-side controls are in the regression set, and they are what make the claim "the hole is mutual absence and not something wider" checkable rather than merely stated. The pair helper recomputes record.hash for the same reason you did: without it every case dies at the digest check and the presence check is never reached, so the tests would pass for the wrong reason. Its docstring says that, so nobody removes the rehash later as redundant.

Seven of the new cases fail on the previous code. Confirmed no overlap with #325, which touches build_assertion only.