How LCP handles confidential, per-transaction, and dynamically generated terms using ephemeral links and encrypted storage. 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:
Server generates custom terms for this buyer/transaction
Server computes the atrHash
Server includes the atrHash in the proposal along with an ephemeral link to the document (this transaction-specific URL overrides the permanent URL from legal-context.json)
Agent downloads the document from the ephemeral link
Agent verifies the hash matches
Agent saves the document locally
Agent proceeds with transaction
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 atrHash 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 atrHash
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 atrHash 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 atrHash
The same terms encrypted with different keys or for different recipients have the same atrHash
Key rotation or re-encryption does not break the hash
Dispute resolution is straightforward: present the plaintext, hash it, compare to the atrHash on record
Privacy Note
The same atrHash 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 atrHash in protocol metadata is visible only to the transacting parties. This is not a privacy concern unless transactions are publicly broadcast.
Placeholder copy reproduced from legalcontextprotocol.org, the Legal Context Protocol, version 1.0 (Apache 2.0). Acme Travel will edit this page.
