Edit History Graph

Unlike a simple linear chain, the Edit History Graph uses a DAG to model complex content creation. This structure allows a single output to be derived from multiple input ingredients (e.g., compositing several images) and for a single ingredient to be used in multiple outputs. The 'acyclic' property prevents circular references, ensuring a mathematically sound and resolvable provenance path from any final asset back to its root sources.

Each node in the graph, representing an asset or an action, is uniquely identified by a cryptographic hash of its content and metadata. A new version's hash is computed over both the new content and the hash of its parent node(s). This forms a tamper-evident chain:

• Altering any past asset immediately changes its hash.
• This break in the chain invalidates all subsequent hashes.
• Verification of the final asset's hash confirms the integrity of the entire history.

The graph is composed of two primary node types that tell the full story of an asset's creation:

• Ingredient Assertions: These nodes document the raw source media, such as a specific RAW photo file or a vector graphic. They are identified by their hash and can include metadata like capture device or creator.
• Action Assertions: These nodes represent operations performed on ingredients, such as c2pa.cropped, c2pa.resized, or c2pa.color_adjusted. They record the software agent used and the parameters of the edit, making the editing process auditable.

Actions within the graph are digitally signed by the actor (human or software agent) who performed them. This is achieved using a Claim Signature backed by an X.509 Certificate issued by a trusted Certificate Authority. This cryptographically binds a verified identity to each edit, providing non-repudiation. A verifier can trace not just what was done, but who did it and when, establishing a chain of accountability from the photographer to the final editor.

A Validator Engine can programmatically traverse the entire graph to verify its integrity. The process involves:

• Hash Validation: Recomputing the hash of every asset and comparing it to the recorded value.
• Signature Verification: Cryptographically verifying every Claim Signature using the signer's public key.
• Certificate Chain Check: Validating the X.509 certificate chain up to a trusted root CA.
• Revocation Check: Querying the CA to ensure the signing certificate hasn't been revoked. This automated process provides a binary, trustworthy validation result.

A standard version history (like in a wiki or Google Docs) is a linear, server-controlled log that can be altered by an administrator. An Edit History Graph is fundamentally different:

• Decentralized Verification: Integrity is proven mathematically, not by trusting a central server.
• Tamper-Evidence: Any post-hoc modification is cryptographically detectable.
• Complex Lineage: It natively models non-linear, multi-source compositions, which a simple linear log cannot represent. This makes it a forensic tool, not just a record.

A sequential chain of hashes linking each version of an asset to its predecessor, forming the cryptographic backbone of the edit history graph. Each node contains:

• The hash of the current asset state
• The hash of the previous node in the chain
• The action assertion describing the transformation Altering any past version immediately invalidates all subsequent hashes, making the edit history graph tamper-evident by construction. This is the same principle underlying blockchain integrity.

A C2PA assertion that describes a specific operation performed on content, forming the labeled edges in the edit history graph. Each action assertion captures:

• Action type: crop, resize, filter, composite, transcode
• Software agent: The application and version that performed the action
• Parameters: Specific settings applied (e.g., resize dimensions)
• Timestamp: When the action occurred This granular documentation enables auditors to reconstruct the exact editing workflow and assess whether transformations were legitimate or deceptive.

Two strategies for attaching the edit history graph to an asset, directly impacting its resilience:

• Hard Binding: The signed manifest is embedded directly into the asset's binary structure (e.g., JPEG JUMBF box). The graph travels with the file, surviving downloads and local transfers.
• Soft Binding: The manifest is stored externally as a sidecar file or cloud URL, referenced by a content hash. The graph is separable from the asset, requiring network access for verification. Hard binding is preferred for consumer-facing provenance; soft binding suits asset management systems where file size is critical.