feat(interoperability): import and export C2PA-compatible authenticity manifests

[enliven17]

Summary

Add bounded C2PA interoperability without treating a C2PA claim as equivalent to a Harpocrates proof.

Motivation

Harpocrates needs this capability to become a production-grade, interoperable evidence protocol while preserving privacy, deterministic verification, and safe failure behavior. The implementation must reuse existing metadata, manifest, ZK, backend, frontend, and Soroban boundaries instead of creating parallel truth sources.

Scope

• Define a versioned mapping between Harpocrates evidence/proof digests and C2PA claims/assertions.
• Parse and validate signed C2PA manifests with strict size, depth, algorithm, and resource limits.
• Export a C2PA-compatible manifest that binds the embedded video hash, metadata hash, proof ID, tier, network, and contract.
• Preserve unknown assertions safely and surface unsupported semantics explicitly.
• Keep C2PA trust status separate from on-chain and ZK verification status in APIs and UI.

Acceptance criteria

• Valid and invalid fixtures cover signatures, malformed boxes, recursion, oversized data, unknown algorithms, and digest mismatches.
• Round-trip export/import preserves canonical Harpocrates bindings.
• Parser fuzzing and production-shaped media tests remain bounded.
• Documentation includes trust-model differences, compatibility matrix, and rollback.
• Existing lint, type checks, tests, builds, contract checks, and privacy guarantees remain green.

Engineering expectations

Use versioned canonical encodings, explicit error/status types, bounded resource consumption, idempotent operations, and privacy-safe observability. Schema, contract, circuit, or artifact changes require migration and compatibility analysis. Cryptographic changes require stable vectors and a written threat model.

Out of scope

Live production deployment, real credentials or sensitive media, unrelated visual redesigns, and broad dependency upgrades not required by this objective.

Definition of done

A maintainer can reproduce success and adversarial failure paths locally, understand the trust and privacy boundaries, operate the feature safely, and roll it back without undocumented state repair.

[Elizabeth-dev270]

@Elizabeth-dev270 has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I would like to fix this quickly

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Elizabeth-dev270 to this issue.

[drips-wave]

Congratulations, @Elizabeth-dev270! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

🧑‍💻 @Elizabeth-dev270: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊