System Design Interview: How Would You Build a C2PA Provenance Verification Service?

Question and scenario

Design a service that verifies C2PA Content Credentials for images, video, and audio. It accepts large media, stores signed manifests, shows edit history, and explains invalid, missing, or untrusted credentials.

What the interviewer is testing

• Correctly separating a C2PA Manifest, Claim, signature, and asset binding.
• Handling large files, asynchronous verification, caching, versioning, and certificate trust.
• Stating that a credential does not prove semantic truth, then designing honest fallbacks and privacy controls.

Clarifying questions before answering

Clarify media types and maximum size, upload versus read-only verification, latency targets, audit retention, who owns trust roots, and whether third parties may fetch manifests. Also clarify whether the service verifies cryptographic integrity only or makes business-level claims about issuers and edits.

30-second answer framework

I would split the system into upload and object storage, manifest extraction, cryptographic verification, a trust directory, result APIs, and an audit index. Media stays in object storage; verification is asynchronous and idempotent by content hash. Results separate signature validity, chain integrity, issuer trust, and unknown states. Versioned caches are invalidated by revocation or trust-directory changes. The product must say that C2PA verifies declared provenance and edits, not semantic truth.

Step-by-step deep answer

1. Issue an upload URL and record asset hash, size, media type, and tenant policy. Enable object versions and checksums.
2. Enqueue verification after upload. A worker extracts embedded or remote manifests and checks Claim-to-asset binding, signatures, timestamps, parent edit chain, and duplicates.
3. Resolve issuer certificates, revocation, and intended use through a versioned trust directory. Store that directory version with every result.
4. Write immutable events and a query index. States should include valid, invalid, untrusted, missing, and indeterminate, with evidence references instead of copying all media.
5. Return a summary, edits, issuer, verification time, and failure reason. Protect previews and manifest downloads with short-lived URLs.
6. Cache hot assets, but key the cache by asset version, specification version, and trust-directory version. Batch-invalidate on revocation or verifier updates.
7. Use rate limits, malware scanning, retries, dead letters, and tenant isolation. Multipart uploads prevent API processes from holding huge files.

POST /v1/assets/uploads
POST /v1/assets/{assetId}/verify
GET  /v1/assets/{assetId}/provenance
GET  /v1/trust-roots/{version}

High-quality sample answer

I would define the trust boundary first: a C2PA Manifest is a verifiable signature over provenance and edit assertions, not a truth classifier. The upload service stores object versions and hashes; asynchronous workers verify asset binding, signatures, edit chains, timestamps, and certificate state. The result API separates integrity, issuer trust, missing credentials, and indeterminate outcomes, and records specification and trust-directory versions. Versioned caches can be invalidated after revocation; immutable audit events and short-lived media URLs protect investigation. This scales without turning “signature valid” into “factually true.”

Common errors

• Treating C2PA as an AI detector or truth oracle.
• Verifying a signature without checking its binding to the current asset bytes.
• Equating a valid certificate chain with a trusted issuer.
• Sending huge media through synchronous API handlers instead of object storage and queues.
• Omitting specification, verifier, and trust-directory versions, making results irreproducible.

Follow-up questions and responses

Why cannot an edit simply keep the old signature?

Editing changes the asset bytes. An editor should append a new Manifest, create a parent-child chain, and bind the current version again. The old assertion can remain history, but it cannot sign the current bytes.

Does a missing credential mean the content is fake?

No. It means there is no verifiable provenance assertion available. Show unknown or missing with coverage limits; do not label content outside the ecosystem as false.

How do you handle trust-directory changes?

Store the directory version and verification time, retain original evidence, and re-verify asynchronously after updates. Publish a new result version with the reason for any state change.

How do you prevent Manifest privacy leaks?

Use tenant- and field-level visibility, return only a necessary summary by default, encrypt sensitive fields, use short-lived download URLs, and audit every access with actor and purpose.