ECP-0024: zkTLS provenance proofs for HTTPS-derived manifests

Status: Draft

Problem / context

We want optional provenance for manifests derived from HTTPS origins (e.g. HLS), without relying on the origin to sign our data. zkTLS can prove that a manifest was derived from a TLS session to a given origin, while keeping the session private.

Decision

Add an optional zkTLS attestation per epoch:

Produce a zkTLS proof that the manifest’s chunk hashes (or their Merkle root) were derived from bytes fetched over HTTPS from a specific origin.
Attach the proof metadata to the manifest as provenance, without replacing our own signatures.

Details

Provenance model

zkTLS is used once per epoch and applies to a specific manifest body.
The proof binds:
- HTTPS origin hostname
- time window / epoch id
- manifest_id (or merkle_root)
The manifest remains signed by local identities; zkTLS does not replace signing.

Data placement

Manifest metadata includes a provenance entry, e.g.:
- provenance.zktls.origin = https://example.com
- provenance.zktls.proof_ref = <hash-or-uri>
- provenance.zktls.scope = merkle_root|manifest_id

Verification

Clients may ignore zkTLS (default) or require it for certain origins.
Verification is a policy decision, not a consensus rule.

Alternatives considered

TLS handshake signatures for data integrity: rejected (TLS does not sign application bytes).
Forcing all origins to sign manifests: rejected (not feasible for public broadcasters).

Rollout / teardown plan

Define provenance metadata fields in ec-core.
Add a proof attachment path in the ingest pipeline.
Integrate a zkTLS provider behind a feature flag.

Teardown: omit provenance metadata and continue using signed manifests.

Open questions

Which zkTLS system to integrate first (TLSNotary-style, zkTLS SDK, or custom)?
Should provenance be per-epoch only, or per-manifest revision?

1.9 KiB Raw Blame History Unescape Escape