Content provenance in DAM: C2PA, Content Credentials & IPTC DigitalSourceType

Why it matters

Generative tools are now part of everyday production: generative fill, background replacement, AI-made product shots, synthetic voices. A DAM receives these assets from agencies, freelancers and in-house tools, and sends them to websites, marketplaces, partners and social platforms. Without provenance, the same problems keep coming back:

• Nobody can tell what is synthetic. An AI-generated image goes out as if it were a photograph. This can break platform rules, press ethics, advertising standards or, in the EU, transparency obligations.
• The evidence disappears on the way out. A file arrives with a signed manifest, but the web rendition is re-encoded and the manifest is dropped. NIST notes that metadata recorded in a file "can similarly be stripped altogether", as often happens when files are shared on social media R17. Tests run by the IPTC photo metadata community found that most social media sites removed or hid embedded rights metadata R20 (Unverified tests from 2013–2015; platform behaviour may have changed).
• Trust is not checked. A manifest can be well formed but signed by an unknown party, or signed with a stolen key R18. If the DAM shows any manifest as "verified", users will over-trust it.
• Labels are inconsistent. One team writes "AI" in the keywords, another uses a custom field, a third does nothing. Search, reports and rules cannot rely on any of them.

Cultural-heritage institutions have reached the same conclusion. A draft framework from the US Federal Agencies Digital Guidelines Initiative (FADGI) treats authenticity and provenance information as something that "requires active stewardship" across the whole lifecycle R18 (draft for public comment, 2026-08-26).

On figures. No independent, freely accessible study was found that measures how much provenance DAM pipelines lose, or what it costs. None is quoted here.

Core concepts

Recommended practices

1. Decide what provenance you need, for which assets, and who owns it

Why. "Support C2PA" is not a requirement. The FADGI framework starts at a planning level: know where provenance information enters, is created, changes and is exposed, and who is responsible. Only then define structures, then standards, then checks R18. It also warns that the right approach depends on the institution's needs and capacity.

How.

• List the asset flows where provenance matters: incoming agency and freelance work, in-house generative tools, editorial or news use, regulated sectors, product imagery shown to consumers.
• Write a short provenance policy: which assets must carry a Digital Source Type value, when a signed manifest is required or only kept, what is shown to users, and what is published.
• Name a provenance owner (often the metadata or brand-governance lead) and involve legal for the AI Act and IT security if the organisation will sign manifests. The roles described in DAM metadata schema & governance apply here too.
• Keep this policy next to your rights policy. Provenance and usage rights are separate, but they meet in the same fields and at the same exit points.

2. Read, validate and record provenance at ingest

Why. Ingest is the last moment when you have the file exactly as the supplier delivered it. If the original manifest is lost there, nothing later can bring it back with certainty. The C2PA Explainer also warns that a missing manifest is not evidence of manipulation: adding provenance is optional, and the specification does not intend to create a "two-tier" media ecosystem R3.

How.

• At ingest, store the original file unchanged and record a checksum, as you would for preservation R22.
• Detect and read embedded C2PA manifests and XMP. Extract the Digital Source Type and the IPTC AI fields into DAM fields (practice 3).
• Validate the manifest and record the result as data: no manifest / well-formed / valid / trusted / invalid, with the signer name, the validation date and the validator version. Also keep the validator's informational status codes, not only the overall result. In particular, assertion.dataHash.additionalExclusionsPresent means that parts of the file besides the manifest are outside the signed hash R1 (see practice 8). Open-source C2PA libraries and a command-line tool from the Content Authenticity Initiative can do this inside an ingest pipeline R23.
• Do not reject assets without credentials by default. Route them by policy: for example, require a Digital Source Type value from the supplier, or flag the asset for review.
• Re-validate later. Trust lists change: the C2PA Interim Trust List was frozen on 2026-01-01 and replaced by the official Trust List and conformance programme R5. A result from last year may not hold today.

3. Add provenance fields to your metadata schema

Why. The manifest is evidence, but people search, filter and apply rules with fields. Embedded IPTC properties also travel to systems that do not read C2PA at all. Google, for example, recommends the Digital Source Type property for AI-generated images, and may show C2PA information in its "About this image" feature R19.

How. Add these fields to your schema and data dictionary:

Classify each field as embedded or DAM-only, and set the direction of sync, as described in DAM metadata schema & governance. Keep the IPTC values in a governed list (Taxonomy, controlled vocabularies & thesauri). For archives that already use PREMIS, the FADGI draft includes a conceptual crosswalk. It maps, for example, PREMIS events to C2PA actions and PREMIS fixity to C2PA content bindings R18.

4. Use the IPTC values precisely

Why. The vocabulary separates cases that matter for disclosure: a photo retouched by hand, a photo with a generated background, and a fully generated image. A vague "AI" tag merges them.

How. Choose the value that describes how the final asset was made. Definitions are paraphrased from the IPTC vocabulary R6:

• Store the full URI, for example http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia, as the IPTC guidance shows R9. C2PA's AI/ML guidance uses the same trainedAlgorithmicMedia value for the output of generative models, so the embedded field and the manifest can agree R4.
• Watch for retired terms in older files: digitalArt and minorHumanEdits were retired in 2024 R6. Map them during migration.
• When a derivative is made in the DAM, update the value. Example: a photo with a generated background moves from digitalCapture to compositeWithTrainedAlgorithmicMedia.
• Do not use the same field for AI-generated metadata such as auto-tags. That is a different question, covered in the AI auto-tagging governance guide (AI auto-tagging governance).

5. When the DAM changes an asset, add to the history

Why. The C2PA guidance says that a tool that modifies an asset should write a new manifest. That manifest records an "opened" action, lists the original as a parentOf ingredient, and uses the most specific action available (for example "transcoded" or "filtered" rather than a generic "edited") R2. The original's history is then kept inside the new manifest.

How.

• Ask your vendor which DAM operations write a manifest (generative edits, crops, format conversion, publishing), which only keep the existing one, and which drop it.
• Decide who signs. A signature binds a named organisation or product to the assertions. The C2PA guidance discusses signer identity by context: an organisation, an employee using an internal PKI, a device R2. If the DAM signs on your behalf, find out which certificate is used and whether it is on the C2PA Trust List. The public conforming-products list and the Conformance Explorer show this R5.
• For composites, record each source asset as an ingredient. The DAM's own relations (derived from, variant of) should match.
• Keep the master unchanged. Edits create new versions or renditions with their own manifests; they do not overwrite the original.

6. Preserve provenance through renditions and transformations

Why. Most provenance is lost here, without anyone noticing. Generating a rendition means re-encoding, resizing or transcoding, and many image libraries drop metadata by default to save bytes. Any change to the pixels also breaks the hard binding of the original manifest R18. A rendition must therefore either receive a new manifest that points back to the original, or be linkable to it in another way.

How.

• Draw up a pipeline matrix: for each output (thumbnail, preview, web rendition, download presets, video proxies, print PDF, dynamic-media URLs) note whether it keeps (a) embedded IPTC/XMP, (b) the C2PA manifest, (c) a new manifest linked to the original.
• Run round-trip tests: send test files through each path, then inspect the output with an independent validator. Use one file with a valid manifest, one with an invalid manifest, one with only Digital Source Type and one with nothing. The FADGI draft lists this kind of evidence (manifest-to-asset checks, derivative-to-source consistency) as proof that provenance stays attached R18.
• Check per-transformation settings. Some delivery services strip metadata unless told otherwise. For example, a CDN image service documents that existing Content Credentials are always discarded unless a "preserve" setting is turned on; when it is on, the service keeps them and appends its own signed actions R24.
• Document known gaps honestly, for example video proxies or trimmed clips, and decide what to do about them (block publication, add a visible label, publish a remote manifest).

7. Plan for delivery, CDN and third-party platforms

Why. Even a perfect DAM cannot control what happens after a file is published. NIST notes that platforms often strip metadata, sometimes to protect privacy, and that provenance at scale depends on platforms not removing it, or on external manifest repositories R17. The C2PA guidance describes two ways to recover from this: external manifests announced through HTTP Link headers, and lookup by soft binding (fingerprint or watermark) in a manifest repository R2.

How.

• For CDN and public links, test that the delivered file still carries the manifest and IPTC fields. Test what is actually delivered, not the DAM preview.
• Where embedding is not possible, consider a remote manifest published at a stable URL. Repositories should let content owners decide which manifests can be queried publicly R2.
• Treat invisible watermarks as a complement, not a replacement. The Explainer describes durable credentials as hard and soft bindings combined R3. The EU Code of Practice asks signatory providers for at least two marking layers, signed metadata and an imperceptible watermark, as long as no single technique meets all the legal requirements R15.
• Keep visible labels for audiences. Indirect disclosure helps machines. People still need direct disclosure where policy or law requires it R21.

8. Show provenance in the DAM without over-promising

Why. The Explainer states that provenance "alone cannot tell you whether the digital content is true, accurate or factual" R3. A green tick next to every manifest teaches users the wrong lesson. NIST also points out that anyone can sign with their own certificate. A validator can then confirm the signature but not the signer's identity, and the interface must make this clear R17.

How.

• Show distinct states: trusted, valid but untrusted signer, invalid (tampered or broken), no credentials. Use neutral wording for "no credentials".
• Show the summary (made with AI or not, by which tool, edited by whom) and give a link to the full manifest or to an external verifier.
• Add facets and saved searches on Digital Source Type and validation state, so that editors can find AI-generated assets before publication.
• Train users: provenance tells you where content came from; it is not a fact-check.

Caveat: a valid signature does not by itself prove the content is unaltered. A C2PA hard binding can leave out byte ranges ("exclusions"). Exclusions exist so that the manifest itself and some metadata can sit inside the file R1. Specification 2.4 says the claim generator must limit exclusions to the manifest store or to asset metadata. A validator, however, is only required to check the range that holds the manifest. Other exclusions do not cause rejection; they produce the informational code assertion.dataHash.additionalExclusionsPresent R1. On 2026-10-02, the independent researcher David Buchanan published a proof of concept. Its exclusion covers the whole file, so the signature and the RFC 3161 timestamp cover an empty string. The image can then be changed after signing while the manifest still validates. He reports that none of the verification tools he could find flagged it as unusual R27. An academic security analysis of C2PA 2.2 had already concluded that exclusion ranges allow undetectable alterations R28. As of 2026-10-13, the wiki found no public response from C2PA or the Content Authenticity Initiative, and no specification or validator change, on this demonstration. What this means for a DAM:

• Before showing a "valid" or "trusted" badge, check what the hard binding covers: the type of hash and its declared exclusions. Treat any exclusion beyond the manifest store, padding and known metadata blocks, and above all one covering most or all of the file, as invalid for display purposes until a person has reviewed it.
• Record the exclusion check next to the validation state (practice 2), and re-run it when validators or the specification change (practice 11).

9. Protect privacy and confidential information

Why. Provenance can reveal more than intended: when, where, by whom and with what tool something was made. NIST warns about this and notes that C2PA recommends opt-in and user control over what is recorded or redacted R17. The C2PA specification makes identity optional and allows assertions to be redacted from ingredient manifests, with the redaction itself recorded R1 R3. The EU Code of Practice encourages providers not to include privacy-sensitive or business-sensitive information in transparency metadata, and to keep such information separate from it where it is needed R15.

How.

• Decide which provenance fields are embedded in public files and which stay DAM-only. Prompts, internal campaign names, photographers' locations and reviewer names are usually DAM-only.
• If the DAM writes manifests, configure which assertions are included. Review thumbnails of ingredients: they can expose an unpublished source image. The C2PA guidance asks implementers to review such data for personal information R2.
• Use redaction, not deletion, when an assertion must be removed from a published chain, so the change remains visible.

10. Align with the EU AI Act and other transparency rules

Why. Article 50 of the EU AI Act sets transparency obligations. Providers of systems that generate synthetic audio, image, video or text must mark outputs in a machine-readable format so they can be detected as artificially generated or manipulated. Deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest, unless that text has undergone human review and editorial responsibility R12. The European Commission states that these obligations apply from 2026-08-02. Systems already on the market before that date have until 2026-12-02 for the marking obligation, and content generated before 2026-08-02 does not need retroactive labelling R13. The Commission's FAQ gives a company that creates AI images for marketing as an example of a deployer R13.

The Commission lists watermarks, metadata identifications, cryptographic methods for proving origin and authenticity, logging and fingerprints among the possible marking techniques R16. The voluntary Code of Practice on Transparency of AI-generated Content was published on 2026-06-10; the Commission and the AI Board consider it an adequate tool to show compliance R14. Two of its measures concern DAM workflows directly:

• Signatory providers will keep existing metadata markings on content their systems transform, and will prohibit deployers and third parties from intentionally removing them in their terms of use R15.
• Signatories that run platforms or otherwise disseminate content to the public are encouraged to preserve metadata markings R15.

The Commission has also published EU icons that deployers may use to label AI-generated content R14.

How.

• With legal, map your roles: where you are a deployer (publishing AI-generated campaign images), and where a tool in your stack, possibly the DAM's own generative features, acts as a provider.
• Never strip AI markings in DAM pipelines unless a documented, legitimate reason exists, and keep that reason on record. Practice 6 is your evidence that you do not strip them.
• Use the DAM to record the labelling decision: is this asset a deepfake under your legal team's reading, which label or icon is required, and who approved it.
• Outside the EU, the FADGI draft also points to the California AI Transparency Act R18. Keep a short register of the rules that apply to your markets.

11. Verify regularly, and carry provenance through migrations

Why. FADGI's highest level is "Validate and Verify": you can show that it works. That means repeatable checks, kept results, and a process for failures and indeterminate results R18. Platform releases, CDN settings and trust lists all change.

How.

• Re-run the pipeline tests (practice 6) after every platform release and CDN change.
• Report monthly: assets missing Digital Source Type, assets whose manifests became invalid or untrusted, published assets labelled AI-generated without a visible label.
• In a DAM migration, export originals byte-for-byte (with checksums), manifests, sidecar files and the DAM-only provenance fields. Then validate before and after. FADGI lists migration tests and before-and-after validation as evidence R18.

Common pitfalls

• "Supports C2PA" taken at face value. Reading, displaying, preserving, signing and validating are different capabilities. Ask which ones, on which file types and in which pipelines.
• Validation done once. Trust status changes with trust lists and certificates. Store the date and re-validate.
• Missing credentials treated as fake. Most content still has none. Absence calls for a policy decision, not an alarm.
• Free-text AI tags. "AI", "GenAI" and "synthetic" in keywords cannot drive rules. Use the IPTC URIs.
• Renditions never tested. The original is fine, but every web image has lost its manifest and its IPTC fields.
• Master files overwritten by edits. The parent ingredient is gone, and the chain cannot be checked again.
• Prompts and names published. Internal or personal data travels with public files.
• "Verified" badges for any signature. Self-signed or unknown signers look the same as trusted ones.
• "Valid" read as "unaltered". A signature can be valid while its hard binding excludes most or all of the file. Check the declared exclusions before relying on the badge R27.
• Watermark or metadata, not both. Each fails differently. Signed metadata is lost when stripped; watermarks are not statistically unique and can be attacked R1 R17.
• Provenance lost in migration. Exports keep the DAM fields but not the original bytes or the sidecar manifests.

How DAM platforms support this

The wiki's solution pages document, with citations, what each platform says about provenance. Look in their AI governance and metadata sections. The examples below illustrate the practices in this guide. They are not a ranking and not a complete list. Many claims are on marketing pages rather than in technical documentation, so test them yourself (practice 6).

• Preservation across pipelines, with documented gaps: Canto documents keeping existing IPTC Digital Source Type, C2PA and XMP provenance across most pipelines since 2026-07-30. It also states that it does not generate missing markers, and lists gaps for some video renditions and for invisible watermarks . Its generative editing feature writes a C2PA manifest .
• Content Credentials support: Adobe Experience Manager Assets lists Content Credentials (C2PA) support ; the same page notes that metadata write-back is disabled by default in the Cloud Service, which matters for practice 6 . Cloudinary announced C2PA support in 2024 .
• Watermark-based provenance alongside C2PA: Bynder documents C2PA Content Credentials and Google SynthID support, and configurable embedding of metadata on download .
• Provenance exposed through the API: Frontify exposes a beta provenance object (credential state, origin, generator, signing certificate) in its GraphQL API . This is the kind of field set that practice 3 recommends.
• Metadata on delivery URLs: Orange Logic documents URL transformations with a metadata strip/keep option , and claims C2PA provenance support .
• Claims to verify: Sitecore Content Hub claims C2PA provenance support on its product page, but the detailed behaviour is marked Unknown in the wiki .

Where a solution page says nothing about provenance, it means the wiki found no public documentation, not that the feature is missing. Ask the vendor the questions in practice 5 and practice 6.