Skip to main content

C2PA conformance FAQs

How do I start the conformance process?​

Start with the C2PA Conformance Program and its expression of interest form. See the program document for details.

A generator product must pass conformance before it can obtain a signing certificate from an CA that has a root cert on the C2PA Trust List. You can use test certificates while preparing for evaluation; however, they are not trusted production credentials.

Sources:

How do I follow up on an application or correct its media types?​

Contact the conformance administrator at conformance@c2pa.org for application-specific issues. For a missing response to an expression of interest, provide the representative email address used in the submission. There is no guaranteed response time.

If a generator application incorrectly omits validation capabilities, request a revision listing both the input media types it validates and the output media types it generates. For example, a product could validate JPEG and PNG ingredients while generating signed JPEG, PNG, WebP, and AVIF assets. Declare your actual capabilities, not this example's list.

Sources:

Does conformance apply to the product or to each end user?​

Conformance is associated with a generator or validator product, whether software or hardware, rather than an individual user.

Creator identity is a separate concern. Use a separately-signed CAWG identity assertion when a product needs to identify its users. Product conformance alone does not establish a user's identity.

Source: Product conformance and identity; August 12, 2026

Does a conformance listing mean the public product already uses production certificates?​

Not necessarily. A product can appear on the conforming products list before public launch. There can also be a delay between listing and deploying a production certificate: the selected CA must verify conformance and the applicant's legal identity.

Listing alone does not make a beta certificate trusted. Evaluate the certificate actually used to sign an asset rather than inferring its trust from the product's listing alone.

Source: Listing, launch, and certificate deployment distinction; May 23, 2026

Why does a generator application ask about validation?​

A generator that ingests assets and creates or appends manifests must invoke validation logic against the C2PA CA and TSA Trust Lists as part of that process. Its declared validate media types describe those inputs; its generate media types describe the outputs for which it creates manifests.

This ingredient validation is distinct from applying as a standalone validator product, which validates assets without generating manifests. Apply separately as a validator product if you are also building a verification tool.

Sources:

How do I choose between backend, distributed, and separate product submissions?​

A distributed generator can divide asset generation, assertions, claim generation, and signing between edge and backend subsystems while functioning as one product. Use mutual authentication between the subsystems and a backend check that the caller is a valid instance of the edge subsystem.

Cooperating subsystems might be submitted as one distributed product, while components that independently generate assets, claims, and signatures would probably require separate submissions.

Do not classify a customer-hosted component solely by whether it runs on a server. Classification requires an assessment of the architecture. Submit an architecture summary and diagram to conformance@c2pa.org, identifying the Target of Evaluation, the components included in the generator product, and how objects submitted for signing are authenticated. Dependency vulnerability scanning requirements can also be a challenge for customer-hosted deployments.

Sources:

Does using the latest SDK make my product conformant?​

No. Use the latest SDK, but remember that SDKs are tools for building products and must be used in a conformant way. Conformance also covers areas beyond software implementation, such as security architecture and key management practices. You also have to submit interoperability test assets as part of the conformance process.

Some common problem areas to check include:

  • Configuring created versus gathered assertions deliberately.
  • Using c2pa.created and c2pa.opened appropriately. Do not describe an existing asset uploaded by a user as newly-created by your product.
  • Validating ingredients with the C2PA Trust List configured.

Sources:

How do I configure trust for ingredient validation?​

Load both the C2PA Trust List and the C2PA TSA Trust List. Fetch their PEM contents, concatenate them, and supply the resulting PEM string through trust.trust_anchors.

For SDK integrations, pass the settings to the builder through a context. Do not use deprecated thread-local settings.

The C2PA Trust List alone may appear to work for timestamp trust because the lists share roots. Include the TSA list to pick up intermediate CA certificates. This is trust-anchor configuration guidance, not a complete answer to every certificate-expiration or point-in-time validation scenario.

Sources:

As of August 10, 2026, these SSL.com endpoints are free for general use with roots on the C2PA TSA Trust List:

  • http://ts-c2pa.ssl.com/rsa
  • http://ts-c2pa.ssl.com/ecc

Trufo's service requires payment and authentication. See the Trufo timestamping documentation.

Sources:

Can evaluation samples use test certificates and still report untrusted?​

Yes. Use SDK test certificates, CA-provided test certificates, or certificates you generate yourself, but evaluation signing certificates cannot be self-signed. Do not interpret "generate your own" as permission to use a self-signed signing certificate.

See the SDK test certificates and a certificate creation walkthrough.

Getting a signingCredential.untrusted error is normal before obtaining a conforming product certificate and does not itself prevent passing conformance.

Sources:

Does adding a trusted manifest remove warnings about earlier untrusted manifests?​

Do not assume that it does. Validators generally show a notice when an asset contains manifests signed with untrusted certificates. The notice may apply to individual manifests, the manifest store, or both, depending on the validator.

When a subsequent conforming generator validates such an asset as an ingredient, it includes the ingredient validation results. If it uses only the C2PA Trust List, an ingredient signed with a certificate from an untrusted private CA will produce signingCredential.untrusted.

This explains a trust-display consequence of a mixed pipeline. It is not a blanket ruling that every trusted/untrusted pipeline is prohibited.

Source: Mixed-pipeline trust behavior; September 10, 2026

How do I put the actions assertion in created assertions?​

Configure builder.created_assertion_labels using base assertion labels. For the Node bindings, use:

const settings = {
  builder: {
    created_assertion_labels: ['c2pa.actions'],
  },
};

const builder = Builder.withJson(manifestDefinition, settings);

Use c2pa.actions, not c2pa.actions.v2. Likewise, do not include assertion instance suffixes such as those in c2pa.ingredient.v3__2.

With only c2pa.actions in that setting, the actions assertion and the automatically created hard binding are created assertions; other assertions are gathered. Add other base labels as appropriate for your implementation. This is not a universal conformance configuration.

As of August 2026, the Reader output flattened created and gathered assertions into one list. Inspect the raw claim bytes to verify placement if your version has this limitation.

Sources:

Should ingredient assertions be created or gathered?​

Mark an ingredient assertion as created in most cases because the claim generator validates it. This is implementation-dependent guidance, not a statement that every assertion associated with an input asset must be created.

Configure assertion placement deliberately rather than relying on the SDK default, which places assertions other than the hard binding in gathered assertions.

Sources:

What does digitalSourceType describe, and when is it needed?​

The digitalSourceType property describes the nature of how an action was performed, such as human, AI, or algorithmic activity. It is not one asset-wide value to copy unchanged through every edit. C2PA 2.4 also allows it to describe an ingredient.

Actions affecting the asset's editorial nature need a digital source type, whereas an unbound watermarking action does not. An original asset should still be referenced as the ingredient associated with c2pa.opened; that action does not require a digital source type.

c2pa.created requires an appropriate digitalSourceType in both C2PA 2.2 and 2.4. See the specification requirement and section 2.4 of the Additional Conformance Requirements. Do not infer that the field is optional merely because an older validator did not report its absence.

Sources:

How should I describe visible and invisible watermarking?​

For invisible watermarking, use c2pa.watermarked.bound or c2pa.watermarked.unbound, depending on whether a c2pa.soft-binding assertion is used with it.

For a visible logo, represent it as a componentOf ingredient and recording c2pa.placed with a parameter referencing that ingredient. For a text-only visible watermark, consider c2pa.addedText.

Do not map all visible watermarking to c2pa.edited with a composite source type.

Source: Watermarking guidance; July 9, 2026

Which action describes publishing an already signed asset?​

Use c2pa.published when releasing an asset to a wider audience, together with any other actions that actually occurred. There is no c2pa.signed action.

Use the official action definitions to describe the operation, rather than inventing an action solely because another signature was produced.

Source: Publication action; May 17, 2026

How should I represent a user's training and mining preferences?​

For a seller opt-out workflow, put cawg.training-mining in gathered assertions. It remains cryptographically protected there, but is not attributable to the C2PA claim generator or signer.

This placement is covered by the manifest signature. If you want to connect the preference to a CAWG identity, reference the assertion through the referenced_assertions array of cawg.identity.

This answers attribution and cryptographic protection; it does not claim that the assertion enforces a user's preference on downstream systems.

Companies do not necessarily respect training-and-mining assertions. Treat the assertion as a statement of preference, not a technical block on scraping or a guarantee against undesired AI use.

Sources:

Why can crJSON show different specVersion values?​

The fields describe different specification versions:

  • claim_generator_info.specVersion in the claim describes the specification version declared by the generator.
  • validationResults.specVersion describes the specification version against which validation was performed. It is not copied from the generator's field.

As of August 2026, a claim could declare 2.4.0 while validation results reported 2.3.0 because the validation value was hard-coded in the SDK implementation. Check the generator value in claim.v2 rather than trying to change the report's validation version through generator metadata.

This distinction explains the field mismatch, not every conformance check. Matching the generator field or passing a rubric alone is not presented here as proof that a product has passed the program.

Sources: