[Feature Request] Support for verifying sidecar/external manifests with decoupled image streams #118
Description
Type: Feature Request
- Problem Statement
In professional media workflows and high-performance asset management systems, image bitstreams and C2PA metadata (JUMBF manifests) are frequently managed as decoupled entities. For instance, the image may reside in a memory buffer or a database BLOB, while the manifest is stored separately as a sidecar file or metadata record.
Currently, the c2pa-c library (and its C++ wrapper) primarily supports verification of embedded manifests. There is no direct, high-level API to perform "Binding Verification" by providing an image stream and a standalone JUMBF block without manually re-encapsulating the image or using temporary disk I/O.
- Proposed Solution
I would like to propose an extension to the Reader API to support sidecar manifest verification. This would allow the library to calculate the hash from a provided image stream and validate it against a separately provided manifest buffer.
- Proposed C++ API Change:
Reader(const std::string &format, std::istream &image_stream, const std::vector<uint8_t> &manifest_jumbf);
- Technical Rationale
The underlying Rust contentauth SDK already possesses the architecture to handle manifests independently via the ManifestStore. Exposing this capability through the C FFI would:
Eliminate Unnecessary I/O: Avoid writing to temporary files just to satisfy the "embedded" requirement.
Zero-Copy Efficiency: Enable verification in memory-constrained or high-throughput environments (e.g., cloud-native image processing).
Support Professional Sidecar Workflows: Align with industry standards where metadata and essence are often delivered via separate channels.
- Requirements
The Reader should perform standard cryptographic binding and integrity checks between the provided stream and the external manifest.
The image_stream should still support Seek to allow for the exclusion-range hashing logic required by the C2PA specification.
- Additional Context
Our software handles its own encoding/decoding, meaning we have the raw image bitstream and the C2PA JUMBF block available in memory as separate buffers. Having this feature would allow us to integrate C2PA verification natively into our memory-resident pipeline without performance penalties.