C2PA Manifest Repositories and Repository Receipts

How C2PA stores, discovers, retrieves, and proves the ingestion of external Content Credentials.

A C2PA manifest repository is an external service or data store that keeps C2PA Manifest Stores available outside the assets they describe. It can serve a Manifest Store that an asset references directly, retain a canonical copy for operational use, support discovery through soft bindings such as watermarks or fingerprints, or perform all three roles.

A repository receipt is different. It is structured evidence that a repository ingested a particular C2PA Manifest Store. C2PA 2.4 defines a repository-receipt assertion so that this evidence can become part of a signed provenance history without implying that the asset content changed.

Neither component replaces the ordinary C2PA trust model. A repository helps a consumer find and retrieve provenance. A receipt can help establish that a repository accepted a manifest. The retrieved manifest must still be parsed, its claim signature and assertions checked, its signing credential evaluated, and its relationship to the asset interpreted correctly.

C2PA Manifest Repositories and Repository Receipts — table 1
In brief A repository is an availability and discovery layer around signed provenance. A repository receipt is evidence of ingestion into that layer. The manifest remains the cryptographically protected record, and independent validation remains necessary after retrieval.

Why manifest repositories exist

Embedding a Manifest Store inside an asset is often the most portable distribution model. The asset and provenance travel together, and a validator may be able to work without a network connection. Real workflows, however, create several reasons to keep the Manifest Store externally as well.

Some formats cannot safely carry arbitrary embedded data, or a product may need to preserve an existing asset without changing its bytes.
A Manifest Store can be larger than the asset or may contain ingredient history that is expensive to duplicate in every rendition.
A publisher, DAM, CMS, or archive may need to search manifest data independently of the media files.
Distribution systems can strip embedded metadata, leaving the asset and its Content Credential decoupled.
A durable-credential workflow may need to resolve a watermark or fingerprint into one or more candidate manifests.
An organization may need controlled public and private views, retention policies, redaction, deletion, audit, or regional storage around provenance records.

The core C2PA specification uses the term manifest repository broadly for an external location where a Manifest Store can be kept and located. The Soft Binding Resolution API describes a more operational service model with interoperable query, fetch, store, and capability routes. A repository may implement that API, a different internal interface, direct URI retrieval, or several access methods at once.

Four related concepts that should remain separate — table 2
Concept	How it is located	Primary purpose	What it does not do
Embedded Manifest Store	Found inside the asset using the format-specific C2PA embedding method.	Keeps the signed provenance physically with the asset.	Does not guarantee that downstream platforms preserve the metadata.
Directly referenced external Manifest Store	Located through an HTTP Link header, XMP provenance URI, format-specific reference, HTML link element, adjacent .c2pa file, or another approved locator.	Makes a particular Manifest Store directly retrievable without embedding it in the asset.	Does not make the remote host trustworthy or excuse hard-binding validation.
Repository record and binding index	Located by a repository-specific manifest identifier or through a soft-binding query.	Retains Manifest Stores and maps discovery signals to active-manifest identifiers.	Does not prove that a returned candidate is the correct provenance for the current rendition.
Repository receipt	Returned by a repository or retrieved through a receipt endpoint, then optionally recorded in an update manifest.	Provides repository-specific evidence that a Manifest Store was ingested.	Does not prove permanent availability, factual truth, or continued repository retention.

Confusing these layers causes avoidable security and user-experience errors. A URI is not a receipt. A receipt is not a trust anchor. A soft-binding match is not a hard-binding success. A repository response is not a factual-truth verdict.

What a manifest repository stores

The central object is the byte-identical C2PA Manifest Store. The repository should retain the signed object that was ingested rather than attempting to reconstruct a semantically similar manifest later from database fields. Re-serialization, recompression, field reordering, or assertion substitution can change cryptographic material and invalidate the record.

A production repository commonly maintains several related record types:

Manifest Store bytes. The complete external object, ordinarily served using the C2PA media type and identified through its active manifest.
Repository-canonical manifest identifier. An identifier for the active manifest of the ingested store. It may be a URN, hash-derived identifier, or another repository-defined value. It is canonical within that repository unless the scheme explicitly provides wider uniqueness.
Soft-binding associations. Zero or more mappings from watermark identifiers, fingerprints, or other supported soft-binding values to an active-manifest identifier.
Repository receipts and verification state. Evidence issued at ingestion and the result of later receipt verification.
Access and policy metadata. Tenant, visibility, authentication policy, public or private view, retention state, deletion state, legal hold, region, and audit references.
Operational history. Ingestion time, binding registration, replacement, retrieval, failed validation, redaction, deletion, and administrative changes.

The repository may also index normalized manifest fields for search, analytics, or policy evaluation. That index should be treated as a derived convenience layer. The signed Manifest Store remains the authoritative object for cryptographic validation.

A repository does not replace C2PA validation

A repository can be well operated and still return a malformed, invalid, untrusted, stale, or irrelevant manifest. It may have stored whatever a caller submitted. It may expose a candidate selected by an approximate fingerprint. Its own account or database could be compromised. For those reasons, the consumer should validate retrieved provenance as though it arrived from an untrusted network source.

At minimum, the consumer should:

parse the returned Manifest Store within strict resource limits;
identify the active manifest and validate its claim structure;
recalculate assertion hashes and validate the claim signature;
evaluate the signing credential, time evidence, revocation evidence, and configured trust anchors;
validate the applicable hard binding whenever the required asset representation is available;
confirm that any soft-binding value used for discovery is actually represented in the recovered provenance and evaluated under the algorithm-specific rules;
preserve whether the result is embedded, directly retrieved, recovered by soft binding, inaccessible, invalid, untrusted, ambiguous, or merely similar.

The detailed validation process is covered in How C2PA Verification Works. The structure being stored is explained in C2PA Manifests Explained.

The repository ingestion workflow

Repository registration should be part of the issuance workflow rather than an afterthought. The exact sequence depends on whether the repository is used only for direct external storage, for durable soft-binding recovery, or for both.

Finalize the protected content. Apply every content-changing operation, including any bound invisible watermark, before the final hard binding is calculated.
Create and validate the standard manifest. Record the hard binding, actions, ingredients, soft-binding assertion where applicable, claim, signature, credential chain, and required evidence.
Store the Manifest Store. Submit a byte-identical copy to the repository. Under the Soft Binding Resolution API, POST /manifests adds the store and returns the active-manifest identifier. A repository may also return a receipt.
Register discovery bindings. If the workflow uses a watermark or fingerprint, associate each soft-binding value with the stored active manifest. The API uses POST /bindings to create an association and PUT /bindings to update one.
Preserve repository evidence. Record the repository URI, manifest identifier, receipt, request identifier, response time, policy, and repository version in the platform audit trail.
Optionally issue an update manifest containing the receipt. Because the repository receipt exists only after ingestion and does not describe a content edit, C2PA requires the repository-receipt assertion to appear only in an update manifest.
Verify the resulting chain. Validate the original standard manifest, the update manifest, the receipt assertion, and the repository proof under the applicable policy before presenting the receipt as verified.
Monitor availability and mapping integrity. Confirm that identifiers remain retrievable, bindings still resolve to the intended active manifest, and public or private visibility remains correct after deployment changes.

The repository ingestion workflow — table 3
Important sequencing detail A repository receipt necessarily describes a Manifest Store that the repository had already ingested. Recording that receipt therefore creates a later provenance event. If the receipt is placed into an update manifest and that updated store is itself ingested, any receipt for the newer store is a separate event. Systems should record only the receipts required by policy rather than creating an unnecessary recursive chain.

The Soft Binding Resolution API

C2PA defines an interoperable Web API for repositories that participate in soft-binding discovery and recovery. It separates finding candidates from retrieving manifests, which is useful because searches can return zero, one, or many manifest identifiers and full Manifest Stores can be large.

The Soft Binding Resolution API — table 4
Route group	Purpose	Representative operations
Query	Find matching active-manifest identifiers from a binding value, uploaded content, or a remote content reference.	GET/POST /matches/byBinding; POST /matches/byContent; optional POST /matches/byReference
Fetch	Retrieve a full or active-only Manifest Store and retrieve or verify repository receipts.	GET /manifests/{manifestId}; GET/POST /manifests/{manifestId}/receipts
Store	Ingest Manifest Stores and create, update, or delete binding associations.	POST /manifests; POST/PUT /bindings; DELETE /manifests/{manifestId}
Service	Advertise repository capabilities to clients.	GET /services/supportedAlgorithms

Query routes

A client that can extract a watermark or compute a fingerprint locally can submit the binding value directly. This minimizes asset disclosure and can reduce bandwidth. A client may instead upload the asset and let the repository compute supported bindings. For large assets, an optional reference-based route allows the service to retrieve the content itself.

The result is a set of candidate manifest identifiers, not a final verification decision. Repositories and clients should preserve the algorithm name and version, binding value, query method, candidate count, match evidence, region or time range where relevant, and repository endpoint used.

Fetch routes

Once a candidate identifier has been selected, the client can retrieve the full Manifest Store or request a reduced store containing only the active manifest. Active-only retrieval can reduce bandwidth, but it may omit earlier manifests and ingredient history needed for a complete provenance view. The consumer should choose deliberately rather than assuming the active manifest is always sufficient.

Receipt endpoints allow a client to retrieve the repository receipt and its verification status, or submit a receipt for verification against a named manifest identifier. This separates receipt evidence from ordinary manifest retrieval while allowing a repository-specific proof mechanism to remain behind a common interface.

Store and service routes

Store operations require stronger authorization than public lookup. A repository should distinguish the right to ingest manifests, create or update bindings, delete records, fetch private records, and verify receipts. Supported-algorithm discovery helps clients avoid sending a binding type the service cannot process, but a capability response is not proof that the algorithm is secure or appropriate for a particular use case.

Direct external retrieval and soft-binding recovery are different

An asset can point directly to an external Manifest Store. For example, a validator may discover a remote manifest through an HTTP Link header, an XMP provenance URI, a format-specific field, an HTML link element, or an adjacent .c2pa object. In this model, the asset supplies the locator.

Soft-binding recovery is used when the direct association is missing, stripped, inaccessible, or being independently cross-checked. The client extracts or computes a content-related signal and asks one or more repositories for candidates. In this model, the content supplies a lookup key rather than a direct manifest URI.

Direct external retrieval and soft-binding recovery are different — table 5
Property	Direct external manifest	Soft-binding repository recovery
Discovery input	A locator associated with the asset or delivery response.	A watermark, fingerprint, asset upload, or asset reference.
Expected result	One intended Manifest Store at the referenced location.	Zero or more candidate active-manifest identifiers.
Best case for hard binding	The external store describes the exact asset bytes and validates normally.	If only metadata was stripped and bytes are unchanged, the recovered store may still validate exactly.
Transformed rendition	The direct reference may be lost or may point to provenance for an earlier representation.	The soft match can remain useful even when the original hard binding does not match the new rendition.
Primary risk	Unavailable or substituted remote object.	Ambiguous match, false match, watermark transfer, index poisoning, or privacy leakage.

The recovery architecture and the difference between exact and approximate association are covered in Durable Content Credentials and C2PA Hard Bindings and Soft Bindings.

Repository receipts

C2PA 2.4 introduced the c2pa.repository-receipt assertion for workflows that need evidence that a repository ingested a Manifest Store. Examples include supporting non-repudiation of ingestion, establishing that a manifest was present in a repository at a relevant time, and recording registration by an external service.

The assertion is intentionally narrow. It records information about the repository and a repository-specific proof. It does not redefine the manifest signature, turn the repository into a certification authority, or guarantee that the repository will retain the object forever.

Why a receipt appears in an update manifest

A receipt cannot normally be included in the standard manifest whose ingestion it acknowledges because the repository has not issued the receipt yet. C2PA therefore requires the receipt assertion, when recorded in a Content Credential, to appear only in an update manifest. The update manifest adds signed information without claiming that the protected content changed and links back to the manifest being updated through the required parentOf ingredient relationship.

Repository-receipt fields

Repository-receipt fields — table 6
Field	Meaning	Implementation implication
repository.uri	Base URI of the repository issuing the receipt.	Identify the service and apply the correct repository trust and verification policy.
repository.manifestId	Repository-canonical identifier of the active manifest in the ingested Manifest Store.	Resolve the receipt to the exact repository record rather than relying only on filenames or asset URLs.
anchor.uri	Location where the ingestion proof can be retrieved or verified.	Treat as an untrusted remote resource and preserve availability and response evidence.
anchor.parameters	Optional repository-specific key-value parameters for accessing the anchor.	Avoid placing secrets in public manifests; define safe handling and redaction rules.
anchor.proof	Repository-defined JSON object that demonstrates ingestion.	The proof format and verification method are repository-specific and must be governed separately.

How a receipt should be evaluated

The update-manifest signature protects the receipt assertion from later modification. It shows what the update-manifest signer recorded. It does not, by itself, prove that the repository actually issued the proof. A robust validator should independently verify the repository-specific proof, either locally or through an authenticated receipt-verification service, and preserve the verification method and time.

A complete evaluation may involve four trust questions:

Manifest integrity. Is the update manifest valid and does it correctly reference the preceding manifest?
Receipt consistency. Does the receipt identify the expected repository and the expected active-manifest identifier?
Anchor proof. Does the repository-specific proof verify under the documented algorithm, key, ledger, log, or service policy?
Repository governance. Is the repository identity, retention promise, incident process, and operational history acceptable for the relying party’s use case?

What a repository receipt can and cannot establish

What a repository receipt can and cannot establish — table 7
Receipt can support	Receipt does not establish alone	Additional evidence that may be needed
That a named repository accepted a Manifest Store under a repository-canonical identifier.	That the asset or assertions are factually true.	Normal C2PA validation, signer identity, capture or workflow evidence, and contextual review.
That a repository-specific proof of ingestion existed.	That the proof is authentic merely because it is copied into a signed assertion.	Independent verification of the anchor proof and repository identity.
That the manifest was present at a time represented by the repository proof.	That the time is a trusted or legally sufficient timestamp in every context.	A trusted time source, proof semantics, and applicable legal or organizational policy.
That a registration event occurred before the receipt assertion was issued.	That the repository still retains or publicly serves the Manifest Store now.	Current retrieval checks, retention records, deletion state, and availability monitoring.
A durable audit link between provenance and an external storage service.	That a recovered manifest hard-binds to a transformed rendition.	Hard-binding validation of exact bytes or clearly labelled soft-binding match evidence.

Multiple repositories and federation

C2PA does not define one universal repository for all content. Different publishers, creative tools, AI providers, archives, enterprises, and industry consortia can operate independent services. A resolver may therefore need a repository-selection strategy rather than one hard-coded endpoint.

Possible discovery approaches include:

querying repositories named by a known watermark or soft-binding algorithm;
using product or publisher configuration to select trusted endpoints;
querying a consortium or industry directory;
consulting a decentralized key-value index that maps a soft binding to repository endpoints and optionally a manifest identifier;
combining several repositories and de-duplicating candidate manifests by cryptographic identity.

Federation does not require a blockchain or distributed ledger. The C2PA guidance discusses decentralized indexes and DLT-backed proofs as optional deployment patterns, not mandatory parts of manifest storage or receipt validation. A conventional authenticated Web service can implement the standard API.

A multi-repository client should preserve which service produced each result, avoid silently privileging the first response, handle duplicate or conflicting candidates, and apply per-repository privacy and trust policies.

Repository lifecycle: updates, deletion, and retention

Repository records have a lifecycle independent of the asset file. C2PA’s API provides operations to add Manifest Stores, create or update binding associations, retrieve manifests, and delete a stored Manifest Store. The specification does not replace the repository operator’s need for durable lifecycle policy.

Repository lifecycle: updates, deletion, and retention — table 8
Lifecycle event	Required operational decision	Recommended evidence
New active manifest	Whether an existing soft binding should continue to resolve to the prior manifest, move to the new one, or return both.	Versioned mapping history, actor, request ID, previous and new manifest identifiers.
Redaction or public/private view change	Whether to issue an update manifest, publish a redacted store, restrict access, or remove discoverability.	Policy version, consent basis, affected identifiers, before/after visibility, audit event.
Deletion request	Whether the store, binding index, derived search data, receipts, logs, and backups are deleted or retained under another obligation.	Deletion state, scope, completion time, exceptions, legal hold, backup-expiry schedule.
Repository migration	How stable identifiers, URLs, receipts, and binding mappings remain resolvable across providers or regions.	Redirect or alias plan, export hashes, chain-of-custody record, post-migration verification.
Incident or compromise	Whether to suspend writes, mark results, rotate keys, invalidate proofs, notify relying parties, or restore from an immutable copy.	Incident timeline, affected objects, proof-verification status, remediation and revalidation results.

A past receipt may continue to show that ingestion occurred even after the Manifest Store is deleted. That distinction should be explicit. Ingestion evidence is historical; availability is a current operational state.

Privacy and governance

Manifest repositories can make provenance more durable, but they can also make content and people more linkable. A soft-binding lookup may reveal that a user is examining a sensitive image. A persistent watermark identifier may connect copies across platforms. An information-rich internal manifest may reveal location, identity, device, rights, or workflow information that was never intended for public query.

The C2PA implementation guidance recommends allowing creators to control which manifests are publicly queryable and to redact or remove repository content where appropriate. A same-origin deployment can simplify browser CORS behavior, but it does not provide additional privacy or security by itself.

A responsible repository design should address:

Visibility. Public, authenticated, tenant-only, embargoed, redacted, and private views should be explicit.
Query minimization. Prefer client-side binding extraction when practical so the full asset does not have to be uploaded.
Lookup logging. Minimize, aggregate, or protect records that reveal which content a person investigated.
Identifier design. Avoid predictable identifiers that enable enumeration, and avoid unnecessary cross-context persistence.
Consent and disclosure. Explain durable lookup, retention, public discoverability, and deletion limitations before registration.
Data residency and retention. Separate the retention of signed manifest bytes, derived indexes, receipts, logs, and backups.
Redaction and erasure. Preserve the difference between a signed historical record, a publicly served view, and operational deletion requirements.

Security threats and controls

A repository receives signed binary objects, untrusted media, external URLs, binding values, credentials, and potentially large requests. It should be treated as an Internet-facing security system, not as a passive metadata bucket.

Security threats and controls — table 9
Threat	Example failure	Key controls
Unauthorized ingestion or binding updates	An attacker maps a popular watermark to a misleading valid manifest.	Strong write authentication, tenant authorization, proof of control, idempotency, approval for high-risk changes, immutable audit.
Repository or index poisoning	A compromised service returns substituted bytes or altered candidate mappings.	Content-addressed storage, hash verification on every read, signed or anchored audit records, separation of object storage and index administration.
Receipt fabrication or downgrade	A copied receipt is presented without verifying its repository-specific proof.	Documented proof schemes, independent verification, key rotation, algorithm policy, verification status stored with evidence.
SSRF and unsafe remote retrieval	The optional reference query fetches internal services, cloud metadata endpoints, or unbounded content.	Destination allow/deny policy, DNS rebinding protection, redirect limits, private-address blocking, size and time limits, isolated fetchers.
Parser and decompression attacks	A crafted asset or Manifest Store exhausts CPU or memory or exploits a media parser.	Sandboxing, bounded recursion and allocation, content-type verification, decompression limits, patched libraries, process isolation.
Enumeration and privacy abuse	An attacker guesses binding values or correlates repeated lookups.	High-entropy identifiers, rate limits, access control, query privacy, minimal logs, anomaly detection.
Availability failure	External provenance disappears during an outage or region failure.	Replication, regional failover, immutable backups, SLOs, caching policy, honest inaccessible status, disaster-recovery tests.
Cross-tenant leakage	One customer retrieves another customer’s private manifests or receipts.	Tenant-scoped identifiers, row and object isolation, authorization at every route, encryption and audit reconciliation.

The repository should never convert network or storage failure into a misleading conclusion about the content. If a documented manifest location is unavailable, the result should remain inaccessible, not “no credential” and not “fake.”

Consider a newsroom publishing a verified photograph that is likely to be resized and stripped of metadata by downstream platforms.

1. Capture and edit. The camera and editing application issue ordinary C2PA manifests. The final publisher rendition receives a bound invisible watermark before signing, plus a soft-binding assertion and the normal hard binding.

2. Repository ingestion. The newsroom stores the final Manifest Store in its repository and receives the repository-canonical active-manifest identifier and ingestion receipt.

3. Binding registration. The watermark identifier is associated with the active manifest. A corroborating fingerprint may also be registered under its own algorithm identifier.

4. Receipt update. The newsroom creates an update manifest containing the repository-receipt assertion and linking to the preceding manifest. The image pixels remain unchanged.

5. Publication. The newsroom publishes the signed asset. The original page may reference the external store directly, and the embedded store travels with the file where supported.

6. Downstream transformation. A social service creates a smaller rendition and removes metadata. The original embedded Manifest Store and direct reference are absent; the original hard binding no longer matches the new bytes.

7. Recovery. A verifier detects the watermark, queries the newsroom repository, fetches the candidate Manifest Store, validates its signatures and assertions, and uses the fingerprint as corroborating match evidence.

8. Presentation. The interface explains that provenance was recovered through a soft binding, identifies the trusted signer and repository, shows the verified ingestion receipt, and avoids claiming an exact hard-binding match to the resized social-media rendition.

This workflow combines several evidence types without collapsing them: exact validation of the signed publisher asset, historical repository-ingestion evidence, and content-level recovery of a transformed copy.

Build, buy, or federate?

Not every organization should operate a public repository. The decision depends on volume, privacy, identity, retention, assurance, and distribution requirements.

Build, buy, or federate? — table 10
Approach	Advantages	Costs and risks	Best fit
Private internal repository	Full policy and data control; simpler tenant and workflow integration.	Limited public discoverability; organization owns availability and security.	Enterprise pipelines, archives, internal AI workflows, regulated evidence.
Managed repository service	Faster launch, shared operational expertise, interoperable endpoints.	Vendor dependency, data-flow concerns, trust and retention terms, migration risk.	Teams needing durable recovery without operating global storage and lookup.
Public industry consortium	Shared discovery and cross-organization interoperability.	Governance complexity, abuse handling, uneven privacy needs, collective incident response.	News, creative, marketplace, or sector-specific trust networks.
Hybrid or federated model	Private authoritative store plus selected public mappings or redacted views.	More identity, synchronization, policy, and conflict-resolution work.	Organizations with sensitive internal provenance and public distribution needs.

The broader system-design choices are covered in the C2PA Implementation Guide.

Production-readiness checklist

The service retains byte-identical Manifest Store objects and verifies their hashes on write and read.
Repository-canonical identifiers are stable, documented, tenant-safe, and not confused with asset URLs or globally unique identities unless the scheme guarantees that property.
Query, fetch, store, binding, receipt, deletion, and capability operations have explicit authentication and authorization policies.
Soft-binding mappings are versioned and auditable; updates do not silently erase prior relationships needed for investigations.
The resolver preserves zero, one, many, conflicting, inaccessible, invalid, and untrusted outcomes.
Retrieved manifests are independently validated, and exact hard-binding success is not inferred from a soft-binding match.
Receipt verification checks the repository-specific anchor proof rather than trusting the receipt assertion solely because it is signed by an update-manifest signer.
Availability, retrieval latency, binding quality, receipt-verification failures, deletion state, and mapping drift are monitored.
Reference-based queries run through hardened, isolated fetchers with SSRF, redirect, DNS, size, and time protections.
Public, private, redacted, and embargoed views are intentional and testable.
Retention and deletion cover Manifest Stores, indexes, receipts, logs, caches, replicas, and backups separately.
Repository migration and incident-response procedures are tested before the service becomes a critical provenance dependency.

Common misunderstandings

Common misunderstandings — table 11
Misunderstanding	More accurate interpretation
A manifest repository is a C2PA trust list.	A repository stores and returns provenance objects. A trust list supplies certificate trust anchors for validating signers.
Anything returned by a known repository is valid.	The returned Manifest Store still requires normal structural, cryptographic, credential, and asset-binding validation.
A repository receipt proves the content was published.	It proves repository-specific ingestion evidence. Public publication is a separate event and may require a publication action or other records.
A receipt guarantees permanent storage.	A receipt is historical evidence of ingestion, not a perpetual availability promise.
External and durable credentials are the same.	An external manifest can be directly referenced. Durable recovery uses a soft binding to rediscover provenance after direct association is lost.
One global repository will contain all Content Credentials.	C2PA anticipates multiple independent repositories and interoperable or federated discovery.
Deleting the repository entry erases the signed history everywhere.	Copies may remain embedded, cached, exported, backed up, or preserved in other repositories and evidence packages.
A soft-binding query should return exactly one answer.	Approximate algorithms and reused or attacked signals can produce zero, one, or multiple candidates.

The simplest mental model

The Manifest Store is the signed provenance object.
An external reference tells a validator where a particular Manifest Store is expected to be.
A manifest repository retains Manifest Stores and may index them for retrieval and durable discovery.
A soft binding helps a client find candidate provenance when the direct store is missing or separated from the asset.
A repository receipt records repository-specific evidence that a store was ingested.
The update manifest is the signed provenance layer used to add that receipt without claiming a content edit.
Independent verification determines whether the retrieved provenance is well formed, valid, trusted, and correctly related to the asset.
Policy and human judgment determine what the combined evidence means for the use case.

Manifest repositories make C2PA operational beyond the boundaries of a single file. They allow signed provenance to be served externally, recovered after metadata loss, searched within controlled systems, replicated for durability, and connected to evidence of ingestion. Their value comes from preserving the distinctions that C2PA depends on: storage is not validation, discovery is not exact identity, a receipt is not a truth certificate, and historical ingestion is not the same as present availability.

Sources and notes

Technical source notes are limited to normative, version-specific, security, and operational claims. The primary sources are published by C2PA.

[1] C2PA Technical Specification 2.4 - External Manifests and references. External Manifest Stores, acceptable reasons for externalization, C2PA media type, and locator methods.

[2] C2PA Technical Specification 2.4 - Manifest discovery and inaccessible status. Validator discovery order, remote references, Link headers, adjacent .c2pa objects, and manifest.inaccessible handling.

[3] C2PA Soft Binding API - Soft Binding Resolution API. Interoperable query, fetch, store, receipt, capability, and federated-lookup operations for manifest repositories.

[4] C2PA Implementation Guidance 2.4 - Manifest repositories and discovery. Repository use cases, privacy controls, same-origin guidance, soft-binding discovery, multiple independent repositories, and optional DLT patterns.

[5] C2PA Technical Specification 2.4 - Repository Receipt. The c2pa.repository-receipt assertion, repository and anchor fields, repository-specific proof, and allowed placement.

[6] C2PA Technical Specification 2.4 - Update Manifests. Update-manifest restrictions, absence of a new hard binding, permitted assertions and actions, and required parentOf ingredient relationship.

[7] C2PA Security Considerations 2.4. External-manifest, validation, content-binding, privacy, and hostile-input considerations relevant to repository services.

[8] C2PA Soft Binding Algorithm List. Authoritative identifiers and interoperability metadata for C2PA-recognized watermarking and fingerprinting algorithms used in soft-binding assertions and repository queries.