Skip to content

Source-attestation roadmap (beyond tamper-evidence) #2

@Haserjian

Description

@Haserjian

Context

Assay currently proves tamper-evidence: receipts were not modified after creation. It does not prove source-attestation: the system could lie when creating receipts. This is a known, documented limitation (PACK_SUMMARY.md "What This Does NOT Prove").

Common question from launch: "if the system is malicious it can emit fake receipts."

Layers to explore

  1. TEE-backed signing -- Sign receipts inside a Trusted Execution Environment so the key is hardware-protected
  2. External witness -- Third-party timestamp authority (RFC 3161) to anchor pack creation time
  3. Transparency log -- Append-only public log (assay-ledger is the start) with inclusion proofs
  4. Cross-system corroboration -- Multiple independent systems producing receipts for the same interaction
  5. Hardware attestation -- TPM/SGX quotes proving the signing environment is unmodified

Priority

Post-launch. The current trust boundary (tamper-evidence + signed packs) is sufficient for v1. Source attestation is the v2 trust layer.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions