C2PA Cloud-Data Assertions: How to Check Required Fields and Rejected Labels

Preserve the assertion and the validator output

Save the exact asset before opening it in a C2PA-compatible validator. Record the source URL or local path, retrieval time, file identifier, validator name and version, active manifest label, claim type, and complete output. This worksheet is an operating recommendation from this article, not a reporting format required by C2PA. Do not replace the file with a screenshot or re-export it before the first validation run.

Find the assertion whose label is c2pa.cloud-data. Copy the fields exactly as the validator exposes them. Keep the outer assertion label separate from the label field inside it, because that inner field identifies the external assertion being referenced. Mark fields that the tool does not display as unreported. Do not infer them from a file name, a badge, or another manifest.

The review has one narrow question: does this cloud-data assertion meet the structural and label rules in the cited C2PA section? It does not decide whether the external content is accurate, safe, or authentic.

Check the four required fields first

C2PA 2.2 requires a c2pa.cloud-data assertion to contain label, size, location, and content_type. If any one is absent, the claim is rejected with assertion.cloud-data.malformed. Record all four field names, the value shown by the validator, and the exact result code in the same case row.

Keep absence separate from a value that looks unusual. The cited rule assigns assertion.cloud-data.malformed when a required field is missing. It does not give this article a basis to invent a field value or declare every unfamiliar value malformed. If the validator supplies only a general failure badge, preserve its full output and leave the missing field unresolved.

The specification also says the location field is validated under the separate external-reference procedure. Record the location result the tool reports, but do not convert this structural check into a detailed account of network retrieval, response content, or hash comparison unless the validator provides those results and the applicable source supports them.

Reject hard bindings placed behind cloud-data

Next, read the inner label value. C2PA rejects the claim with assertion.cloud-data.hardBinding when that external assertion label is c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, deprecated c2pa.hash.bmff.v2, or c2pa.hash.bmff.v3. Copy the literal label and code. Do not shorten the list to a general statement that all hashes are forbidden.

This rule is about which assertion labels may be referenced through c2pa.cloud-data. A hard-binding rejection does not by itself show that asset bytes changed, identify an editor, or prove a depicted event false. Those questions require the relevant asset-binding result and other evidence.

Use a separate row for each cloud-data assertion. If one row carries a listed hard-binding label and another carries a different label, do not merge their outcomes into one badge. The record should let a later reviewer trace each exact label to the validator result.

Apply the update-manifest actions rule

When the manifest is an update manifest, the external assertion label must not be c2pa.actions or c2pa.actions.v2. Either label causes rejection with assertion.cloud-data.actions. Record whether the tool identified the manifest as an update manifest, the literal external label, and the exact code.

Do not apply this result merely because the word actions appears elsewhere in an output. The cited condition depends on both the manifest type and the external assertion label. If the validator does not expose the manifest type, leave that part unconfirmed instead of assigning the code yourself.

A useful case table contains the asset identifier, manifest label and type, outer assertion label, label, size, location, content_type, location-validation result if reported, exact failure or success status, validator version, and unresolved fields. Attach the complete output so another reviewer can reproduce the reading.

Report a bounded conclusion

A passing structural review supports a limited observation that the inspected cloud-data assertion met these rules in that validator run. It does not verify the referenced statement, establish signer trust, validate the claim signature, or authenticate a person, caption, date, location, or event. A rejection identifies a specific conformance problem; it is not a verdict that the media is synthetic or deceptive.

If you also analyze the preserved asset with DeepFakeCheck, keep that probabilistic signal outside the C2PA table and link it to the exact file. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. DeepFakeCheck does not validate c2pa.cloud-data assertions or issue the failure codes in this article.

Close the record with the saved asset, validator output, field table, any separate external-reference or asset-binding results, original publication checks, and the human decision.

Sources

• C2PA, “C2PA Technical Specification, c2pa.cloud-data validation”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_c2pa_cloud_data_validation