Introduction

Overview

Que Manifests are the fundamental building blocks for establishing and verifying the provenance of digital assets within the Que platform. They serve as a cryptographically verifiable record of an asset's origin, authorship, and processing history. By attaching manifests, Que ensures that the authenticity and integrity of digital content can be reliably tracked and validated, offering transparency in an increasingly complex digital landscape.

How Manifests Are Stored and Retrieved

A collection of manifests, known as a manifest store, is securely linked to a digital asset. This manifest store contains crucial provenance information. When an asset is created or modified using a Que-compatible tool or service, new manifests are added to its store, extending its verifiable history.

Que can discover and process a manifest store linked to an asset in three primary ways:

1. Directly Embedded: The manifest data is included within the asset's metadata itself. This is the most common method for many image and video formats.
2. Sidecar File: The manifest is stored in a separate file located alongside the asset. This file shares the same base name as the asset but uses a .c2pa extension (e.g., myphoto.jpg would have myphoto.c2pa).
3. Remote URL: The asset's metadata contains a reference (URL) pointing to an external manifest store hosted on a network. This allows for dynamic and potentially large manifest stores to be managed independently of the asset file size.

To determine if an asset has Que provenance, the Que service checks for the presence of a manifest store in the order listed above. This ensures comprehensive coverage and reliable discovery of provenance data.

The most-recently added manifest in a store is considered the active manifest. This active manifest is cryptographically bound to the asset, typically by a hash, ensuring its validity and direct connection to the content.

Binary vs. JSON Manifests

The underlying C2PA specification defines manifests as a binary structure, often encapsulated in the JPEG universal metadata box format (JUMBF). This binary format is highly efficient for embedding within assets but can be complex and challenging for direct human interaction or programmatic generation.

Que simplifies this by providing a declarative JSON manifest structure. This human-readable format acts as an abstract translation layer, making it much easier to understand, create, and manage manifest content. You describe the desired provenance information using a clear JSON syntax, and the Que API or SDK handles the conversion into the appropriate binary C2PA format for embedding. This approach allows developers to focus on defining the asset's history without grappling with low-level binary complexities.

Cryptographic Time-stamps

What are Time-stamps?

A time-stamp in the context of C2PA is a cryptographic proof that a particular piece of data (specifically, the C2PA claim data structure within a manifest) existed at a certain date and time. It functions much like a digital notary service. This proof is typically provided by a trusted third-party Time-Stamp Authority (TSA) that adheres to standards like Internet X.509 Public Key Infrastructure Time-Stamp Protocol (RFC 3161).

Why use Time-stamps?

Time-stamps are critical for maintaining the long-term validity and trustworthiness of signed manifests. Without a trusted time-stamp, a manifest's signature can become invalid when the associated signing credential (e.g., a digital certificate) expires or is revoked. By including a time-stamp, you establish an independently verifiable and auditable record of when the signature was applied, preserving its integrity even if the original certificate's validity period ends.

How to use Time-stamps

When signing an asset with Que, you can configure the use of a time-stamping service. The Que API will integrate with a compliant TSA to embed this proof into your manifest.

For programmatic signing via the Que API, the timestamper property within the CawgIdentityDto schema (for CAWG identity assertions) or equivalent configuration for main signing allows you to specify a TSA, either by a predefined service ("digicert") or a custom URL. The time-stamp then appears in the evidence object of the SignResponse when reading the manifest store.

Further Reading

Explore related concepts to deepen your understanding of Que's provenance features:

• Que Assets: How Que handles digital assets
• Signing Assets with Que
• Verifying Assets with Que
• Managing Remote Manifests
• C2PA Specification: The foundational technical specification for Content Authenticity Initiative.
• JUMBF (ISO/IEC 19566-5): A framework for JPEG standards to add universal metadata.