Transaction-Time Verification

This section is advisory.

Transaction-time verification is the key innovation of the ALC standard beyond discoverability. The insight is simple: the correct moment to fetch, verify, and save terms is not when the agent first discovers a service — it is at transaction time, right before the agent pays.

---

Two Moments

Discovery time — The agent visits /.well-known/legal-context.json to understand how a service handles legal terms. This is informational. The agent may browse terms, evaluate the vendor, and decide whether to engage.

Transaction time — The correct moment to fetch, verify, and save the terms. This is when the contentHash matters (Level 2+).

---

The Proposal-Phase Pattern

Every major agentic commerce protocol has a two-phase flow — propose, then execute:

At Level 2+, the contentHash SHOULD be included in the proposal phase. Including it in the proposal allows the agent to verify before paying. Including it only in the receipt is valid but weaker — the agent cannot verify before committing.

---

Agent Verification Flow (Level 2+)

1. Receive the proposed contentHash from the server (in the proposal)
2. Fetch the terms document from the URL provided
3. Compute SHA-256 of the downloaded document
4. Compare to the proposed contentHash — if mismatch, halt
5. Save the document locally
6. Proceed with payment
7. Receive receipt containing the same contentHash — confirmation of what was agreed

This eliminates both race conditions (terms changed between discovery and transaction) and malice (server claiming different terms after the fact). The agent verifies at the moment that matters — right before it pays.

---

Level 1 Behavior

At Level 1 (no hash), there is no contentHash in the proposal. The terms URL from legal-context.json is the reference. The agent should still fetch and save the terms at transaction time as evidence of what it saw, even without a hash to verify against.

At Level 1, the discovery-time terms and the transaction-time terms are assumed to be the same; the agent has no mechanism to detect a change between discovery and transaction.

---

Document Preservation

Agents SHOULD save a copy of the terms at transaction time regardless of level. At Level 2+, agents SHOULD verify the contentHash against the downloaded document before proceeding.

The vendor does not need to guarantee long-term availability of the document at the URL. The document only needs to be downloadable when the agent transacts. After that, the proof lives with the parties — the document in their possession and the hash in the receipt.

A hash without a document is a proof without evidence.

---

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 is 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.

---

Hash-Then-Encrypt for Persistent Private Terms

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.