55 lines
1.9 KiB
Markdown
55 lines
1.9 KiB
Markdown
# 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?
|