Non-redactable assertions

[andrewDworschak]

• I have read the CLA Document and I hereby sign the CLA.

---

This topic came up in the June 2, 2025 NA/EU meeting and we decided to create this issue as a prompt to revisit the discussion in a future meeting.

Are there any circumstances in identity or metadata assertions where the redaction of an assertion should trigger a validation failure?

This idea takes its queue from https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_redaction_of_assertions, specifically:

Claim generators shall not redact assertions with a label of c2pa.actions or c2pa.actions.v2 as this assertion type represents essential information in understanding the history of an asset. They shall also not redact any hard binding to content assertion - either a c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or c2pa.hash.bmff.v3, as these assertions are necessary for determining the integrity of the asset.

My initial thoughts on this are:

1. If redaction is disallowed, the indicator of that has to live one level up the Merkle tree (i.e. in the claim) or the indicator could be erased without a trace.
2. It's easy to imagine cases where some identity assertions and some metadata assertions should be redacted, so those assertions would either need a mechanism to mark themselves as permanent in the claim data, or be marked with as different type of assertion.
3. This topic came up in the context of rights, which falls outside the purview of this group. There are also some implementations of identity hooks that would benefit from a permanence indicator in an assertion.
4. The solution I'd like to see would be for an assertion to be able to mark itself as permanent in the claim, alongside the place where claim references that assertion. This would provide maximum flexibility for claim generators and other identities to place permanent info that should not be removed into a claim, while still allowing for more sensitive information to be removable.

In a future discussion, I recommend that we 1. decide whether this is a CAWG issue, a C2PA issue, or something else. 2. discuss which use cases there are and whether they're are strong enough to warrant adding it to the standard.

[scouten-adobe]

@scouten-adobe to talk with @lrosenthol about whether this is a C2PA issue or a CAWG issue.