Claim Signature

The signature guarantees that the assertions have not been altered since the moment of signing. The process works by first hashing the canonicalized claim data (e.g., JSON-LD) to produce a fixed-size cryptographic digest. The private key then signs this digest, not the raw data itself. Any subsequent modification to a single bit of the original assertions—such as changing a timestamp or creator name—will produce a completely different hash, immediately invalidating the signature upon verification. This property is fundamental to tamper-evident metadata.

Non-repudiation cryptographically prevents the signer from plausibly denying they generated the signature. Because the signature can only be created with access to the private key corresponding to a specific public key, and that public key is bound to an identity via an X.509 certificate issued by a trusted Certificate Authority, the signer cannot later claim the signature was forged. This creates a legally and technically defensible audit trail, binding an identified actor to a specific set of provenance claims.

Verification of the signature authenticates the origin of the assertions. The verifier uses the signer's public key (retrieved from a validated certificate chain) to decrypt the signature and compare the result against a freshly computed hash of the claims. A successful match proves two things simultaneously:

• The data has not been modified (integrity).
• The entity controlling the private key associated with that public key is the true originator of the signature. This process is the core function of a validator engine.

A claim signature is meaningless without a chain of trust linking it to a trusted root. The signature itself contains or references the signer's X.509 certificate, which is signed by an intermediate CA, which is ultimately signed by a root Certificate Authority. The verifier must validate this entire chain, checking that no certificate has expired or been revoked (via OCSP or CRLs). The root CA acts as the trust anchor, and its presence in a verifier's trust list is what ultimately validates the identity behind the signature.

To prevent a signer from backdating a signature or using a key after it has been revoked, a claim signature is typically counter-signed by a Timestamp Authority (TSA). The TSA receives the signature, appends a precise, trusted time, and signs the combined data. This creates a trusted timestamp token that cryptographically proves the signature existed before a specific moment. This is critical for long-term validation, ensuring the signature remains verifiable even after the original signing certificate expires.

A single claim signature can sign over a complex, structured set of multiple assertions. Using standards like C2PA, a signature can bind together a creative work assertion, an action assertion (e.g., 'cropped'), and multiple ingredient assertions into one verifiable unit. The signature covers the entire data structure, meaning the relationship between these assertions is also integrity-protected. This allows for the construction of a verifiable, non-repudiable provenance chain where each link is a distinct, signed set of claims.

The foundational process that makes claim signatures meaningful. It creates an immutable, mathematically verifiable link between a digital asset and its origin metadata using:

• Digital signatures to assert identity and intent
• Hash chains to link sequential edits
• Tamper-evident structures that invalidate on any modification

A claim signature is the cryptographic act that executes this binding for a specific set of assertions.

A structured, digitally signed statement within a C2PA manifest that makes a specific claim about content. Each assertion is the payload that a claim signature protects.

Common assertion types:

• Creative assertions: authorship, creation date, location
• Action assertions: edits performed, software used, parameters applied
• Ingredient assertions: source media incorporated into composites

The claim signature binds all assertions together, ensuring none can be added, removed, or modified without detection.

The trust anchor that gives a claim signature its real-world identity binding. An X.509 certificate:

• Binds a public key to a verified organizational or individual identity
• Is issued by a trusted Certificate Authority (CA) after identity vetting
• Forms the root of the signature validation chain

When a claim signature is verified, the validator walks the certificate chain to ensure the signer's identity is authentic and the certificate hasn't been revoked.

A process that cryptographically binds a document's hash to a specific, verifiable point in time using a trusted Timestamp Authority (TSA).

In claim signatures, timestamps serve two critical functions:

• Non-repudiation: proves the signature existed before a certain moment, preventing backdating
• Long-term validation: allows signature verification even after the signing certificate expires

The TSA's signed timestamp token becomes part of the overall provenance credential.

The complete cryptographic validation process that confirms a claim signature's integrity and authenticity. A validator engine performs:

1. Hash verification: confirms content matches the signed hash
2. Signature validation: cryptographically verifies the signature against the signer's public key
3. Certificate chain walking: validates the X.509 trust chain to a root CA
4. Revocation checking: queries OCSP/CRL to ensure no certificates were revoked
5. Trust list consultation: confirms the signer is on an approved trust list

Two strategies for attaching a claim signature and its manifest to digital content:

Hard Binding:

• Manifest embedded directly in the file's binary structure (e.g., JPEG header via JUMBF)
• Survives file copying and basic transfers
• Increases file size slightly

Soft Binding:

• Manifest stored externally as a sidecar file or cloud URL
• Referenced by a content hash stored in the asset
• Requires network access for verification
• Useful when embedding isn't technically feasible