Private and Custom Terms

This section is advisory.

Not all terms are public. Many commercial relationships involve confidential pricing, custom agreements, or dynamically generated terms specific to a single transaction. The LCP standard handles these naturally through the transaction-time verification model.

---

The Ephemeral Link Pattern

The transaction-time model naturally solves the privacy problem. A seller can propose completely custom, private terms for a specific transaction:

1. Server generates custom terms for this buyer/transaction
2. Server computes the contentHash
3. Server includes the contentHash in the proposal along with an ephemeral link to the document (this transaction-specific URL overrides the permanent URL from legal-context.json)
4. Agent downloads the document from the ephemeral link
5. Agent verifies the hash matches
6. Agent saves the document locally
7. Agent proceeds with transaction
8. Ephemeral link expires — the document is gone from the server

The terms were never public. No permanent URL. No access control system needed. No encryption. No key management. The document existed at one URL for long enough for the buyer to download, and then it's gone. Both parties have a copy. The contentHash in the receipt is the proof.

This naturally supports:

• NDAs and confidential agreements — only the two parties ever see the terms
• Custom per-customer pricing and terms — every proposal can have different terms with a different contentHash
• Settlement agreements — terms exist only between the parties
• Dynamically generated terms — assembled at proposal time based on the specific transaction

Ephemeral links SHOULD use unguessable URLs (e.g., containing a cryptographic random token) and SHOULD expire after a short period (minutes, not hours). The ephemeral link MUST be served over HTTPS.

---

Encrypted Persistent Storage

For private terms that require long-term storage (not ephemeral), the document may be encrypted before storage. In this case: hash the plaintext, then encrypt.

The contentHash SHOULD always identify the content — what the terms actually say — not a specific encrypted artifact. This means:

• Any party with access to the decrypted document can verify the contentHash
• The same terms encrypted with different keys or for different recipients have the same contentHash
• Key rotation or re-encryption does not break the hash
• Dispute resolution is straightforward: present the plaintext, hash it, compare to the contentHash on record

---

Privacy Note

The same contentHash appearing across multiple transactions only reveals a correlation if those transactions are publicly broadcast (e.g., on a public blockchain). Most agentic commerce transactions are private HTTP exchanges between two parties. The contentHash in protocol metadata is visible only to the transacting parties. This is not a privacy concern unless transactions are publicly broadcast.