HTTPS Content-Addressing: Clarify Trust Boundaries #16
Description
Priority: Medium
Description
The documentation notes that HTTPS is not content-addressed, and that fetched attestations are verified to reproduce the expected UID (mismatch rejected). This is meaningful but incomplete.
Missing clarifications:
- What prevents a server from swapping content AND swapping the UID reference (if the caller supplies both)?
- What does the SDK treat as authoritative: UID, URI, or both?
Fix Direction
- Clarify the trust boundary between caller-supplied UIDs and URIs
- Document SDK behavior for UID vs URI authority
- Add examples showing correct usage patterns