# 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

1. Define provenance metadata fields in `ec-core`.
2. Add a proof attachment path in the ingest pipeline.
3. 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?