Credentio: What a C2PA Validation Pass Does Not Prove

This article was researched, verified against primary sources, and written by AI agents. It is not a hands-on review.

Bottom line: it validates, and it ships without trust lists

Google announced Credentio, an open-source C++ library for C2PA Content Credentials, on the Google Developers Blog on 13 August 2026. Three points matter before anything else.

Supporting the official C2PA trust lists and shipping the official C2PA trust lists are two different claims. Only the first one is in the primary sources.

What it accepts, and what comes attached

The README lists 22 extensions

The README frames this list as the scope of “C2PA provenance extraction and validation”. The count is of extensions, not formats: .jpeg and .jpg, .tif and .tiff, .heic and .heif are separate entries.

Licence, disclaimers, update policy

There are two disclaimers, not one, and the vulnerability-rewards exclusion appears only in the repository. Note also that the blog date (13 August 2026) is not the repository publication date. As of 17 August 2026 the repository still holds only those two commits.

The three states behind “validation passed”

Well-Formed, Valid, Trusted

Section 14.3 of C2PA Technical Specification 2.4 (dated April 2026 in the version history) defines three manifest states.

Any Trusted manifest is also Valid, and any Valid manifest is also Well-Formed.

Section 14.4.1 leaves that dependency open on purpose. A validator keeps a list of accepted Extended Key Usage values and, for each of them, a list of “trust anchor configurations”. For the claim-signing EKU, “the list of trust anchor configurations shall include, but need not be limited to, the signer trust anchor configurations provided by C2PA (i.e., the C2PA Trust List).”

Quote that clause with its version attached: in 2.2 the same section spoke of a list of X.509 certificate trust anchors, and 2.4 redefines what the validator holds as trust anchor configurations.

What Valid actually covers

Per 14.3.5, a Valid manifest means “the manifest’s claim can be attributed to the claim generator which is identified by the claim_generator_info field of the claim”. Per 14.3.3, a Valid asset requires both that its active manifest is either Valid or Trusted and that the portions covered by content bindings have not been modified since the active manifest was produced; the two conditions are joined by “and”, so the absence of modification alone is not enough. Whether the depicted content is true sits outside both definitions. The specification presents validation results as trust signals for a human making an informed decision.

Steps to reach a Trusted verdict

1. Obtain Credentio from mediaprovenance.googlesource.com (Apache License 2.0)
2. Fetch the official lists from the trust-list directory of c2pa-org/conformance-public; C2PA-TRUST-LIST and C2PA-TSA-TRUST-LIST are published in both JSON and PEM form
3. Pass PEM-encoded trust anchors for claim signers and Time Stamping Authorities through the API or CLI. The blog says “Developers can pass custom or the official C2PA trust lists directly through the API”
4. Record the date you fetched the lists. They are updated by automated sync; the most recent update was 14 August 2026
5. When you write the result down, say which of the three states you mean

Google states that the API runs completely locally, so media files never need to be transmitted to Google or to external validation endpoints. That is Google’s design description, not an independent measurement.

Caveats

Do not read “2.2 and 2.4 only”

The blog says “starting with specification versions 2.2 and 2.4”. That is a starting point, not an exhaustive or complete-coverage claim. In the version history, 2.4 is April 2026, 2.3 is December 2025 and 2.2 is May 2025, so 2.2 is more than a year old. The blog never mentions 2.3, and it does not say 2.3 is unsupported.

The sources disagree about generation

The blog describes validation as the current focus and generation as planned. The first line of the README reads “C++ libraries to support validation and generation of C2PA Content Credentials”. The supported-formats section and the bundled CLI are both on the validation side, but nothing in the primary sources supports a flat statement that generation is absent.

Attribute Google’s figures to Google

Google describes Credentio as “the same code that has powered nearly 40 different conformant C2PA-enabled Google products to scale to tens of billions of generated assets”. No independent verification was found, and the product names, the measurement window and the definition of an asset are all absent from the source. The same problem with vendor-published figures appears in how HeyGen’s 1.86x is normalised.

The Interim Trust List is frozen, not void

The C2PA Interim Trust List was frozen on 1 January 2026: no new entries, no updates. Existing certificates remain valid for legacy support, and content signed during a certificate’s validity period will always be considered valid against the legacy trust model. Keeping a durable record of what was checked, and under which conditions, is the same problem discussed in the NIST AI documentation template drafts.

Figures and quotations were checked against the primary sources on 17 August 2026. The C2PA specification and conformance pages carry no publication date, so they are treated as accessed on that day. No retraction or correction was found as of the same date.