Auto-generated claim thumbnails placed in gathered_assertions instead of created_assertions

[erik-sv]

Summary

The Builder places auto-generated claim thumbnails in gathered_assertions
rather than created_assertions. The claim generator creates these thumbnails,
so C2PA spec section 14.3 requires them in created_assertions.

Root Cause

sdk/src/builder.rs, line 1422 (v0.78.4):

// todo: add setting for created added thumbnails
add_assertion(&mut claim, &thumbnail, false)?;

The false argument routes the thumbnail through claim.add_assertion(),
which passes add_as_created_assertion=false to add_assertion_impl(). The
claim_assertion_type() function then falls through to Gathered unless the
caller has configured created_assertion_labels in their settings.

Spec Reference

C2PA Technical Specification v2.3, Section 14.3:

The created_assertions field SHALL contain references to all Assertions
that were created by the Claim Generator for this Claim.

The claim generator creates the thumbnail during signing. It is not gathered
from an ingredient or a prior manifest.

Fix

Change false to true:

add_assertion(&mut claim, &thumbnail, true)?;

This matches the existing behavior for c2pa.hash.data assertions, which are
already routed to created_assertions via the HASH_LABELS check in
claim_assertion_type().

Workaround

Consumers can set builder.created_assertion_labels to include
c2pa.thumbnail.claim in their Settings/Context configuration. This works but
requires every downstream caller to compensate for what should be the
library's default behavior. It also depends on the Context being properly
attached to the Claim, which has known inconsistencies with thread-local
settings.

Impact

Any C2PA Conformance Program Level 1 Generator Product submission that uses
c2pa-rs auto-thumbnail generation will have thumbnails in the wrong claim
field. The C2PA Conformance Program Administrator flagged this during our
submission review.

[github-jira-sync-bot]

❌ Something went wrong. Cannot create Jira issue.

[gpeacock]

This change would leave us with no option to have these thumbnails be added as gathered. I'm not sure if that's ok unless the spec makes it as clear as it does with hard bindings. It would add an inconsistency since some thumbnails would be created while others could be gathered. But I suppose there are cases where that is expected.

We also generate thumbnails for ingredients. If the ingredient has a valid manifest with a thumbnail, we add an ingredient thumbnail that references the thumbnail in the manifest. Would this be a created or gathered thumbnail? I'd presume it is created since the claim_generator created the assertion, even though it references something that may be gathered.

[erik-sv]

@gpeacock Good questions. Two parts:

1. "No option to have thumbnails as gathered"

The library already takes this position for hard bindings. HASH_LABELS unconditionally routes c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.bmff, and c2pa.hash.collection to created_assertions in claim_assertion_type() - no settings override, no gathered option. The claim generator creates these during signing. The same applies to auto-generated claim thumbnails.

The created_assertion_labels workaround inverts the burden: every downstream caller must configure the library to produce spec-compliant output. The default should be correct. If a future use case needs an override in the other direction, a gathered_assertion_labels setting could provide that escape hatch.

2. Ingredient thumbnails

The spec classifies by who authored the assertion, not where the underlying data came from. When the claim generator creates a new c2pa.thumbnail.ingredient.* assertion - even one that references or derives from an ingredient's existing thumbnail - the claim generator authored that assertion. It belongs in created_assertions.

Your own intuition is right: "I'd presume it is created since the claim_generator created the assertion, even though it references something that may be gathered."

This parallels c2pa.hash.data exactly. The hash covers the entire asset (which may contain gathered ingredients), but the hash assertion itself is created by the claim generator.

For context: the C2PA Conformance Program Administrator flagged this during our Level 1 Generator Product submission review. The current behavior produces non-conformant output.