# Legal Context Protocol — Condensed Specification This is a condensed rendering for machine ingestion. Its section numbering is its own and does not match the published specification, and it omits several sections and all appendices. Cite the published specification: https://legalcontextprotocol.org/standard Version: 1.0 Date: June 24, 2026 Authors: David Fisher (Integra Ledger), David Berger (Integra Ledger) Status: Draft — released for community review License: Apache 2.0 --- ## 1. Abstract The Legal Context Protocol (LCP) is an open standard for discovering the legal context of agentic commerce transactions. The standard defines a well-known URI (`/.well-known/legal-context.json`) where any service publishes a reference to its legal terms. The standard requires no specific technology — no blockchain, no cryptography beyond standard HTTPS, no API, no third-party service. Any web server can implement it. Beyond the normative core, this document provides advisory guidance on progressively stronger bilateral evidentiary records — provable terms, signed acceptance, and integration with legal and recourse infrastructure such as dispute resolution. --- ## 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals, as shown here. --- ## 3. Terminology - Discovery document: The JSON file served at `/.well-known/legal-context.json`. Contains references to the service's legal terms and optional metadata. - Terms document: The standalone, downloadable legal terms file referenced by the `terms` field in the discovery document. May be any format: PDF, JSON, Markdown, plain text, or other. - ATR hash: A SHA-256 hash of the **Agentic Transaction Record** (ATR) — the ATR is the terms document itself, and the ATR hash is its digest. `0x`-prefixed hexadecimal (66 characters). Identifies the exact document and proves it has not been altered. - Legal context: The combination of terms, jurisdiction, dispute resolution process, and temporal obligations governing a transaction. - Clause identifier: A content-addressed identifier for a dispute resolution clause, in the format `sha256:0x` followed by 64 hex characters. Enables verification that a clause matches a known published standard. --- ## 4. The Standard (Normative Core) ### 4.1 Well-Known URI A service implementing this standard MUST serve a JSON document at: https://{domain}/.well-known/legal-context.json The document MUST be served over HTTPS. The TLS certificate provides domain identity anchoring. ### 4.2 File Format The discovery document MUST be valid JSON (application/json). ### 4.3 Legal Terms Are a Document The legal terms referenced in legal-context.json MUST be a standalone file — a discrete, downloadable artifact. Not a section of a webpage. Not dynamically rendered HTML. The file format does not matter: PDF, Word, Markdown, JSON, plain text, or any other format. The file MUST be served via standard HTTP(S) GET. The server SHOULD include a Content-Type header declaring the file format. ### 4.4 Required Fields ```json { "terms": "https://example.com/terms/v3.pdf" } ``` | Field | Type | Required | Description | |-------|------|----------|-------------| | terms | string | REQUIRED | Absolute HTTPS URL of the legal terms document. MUST return a standalone, downloadable file. | ### 4.5 Optional Fields ```json { "terms": "https://example.com/terms/v3.json", "termsFormat": "json", "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069", "acceptanceRequired": true, "disputeResolution": { "method": "Dispute Resolution Service Rules", "jurisdiction": "New York, USA", "contact": "disputes@example.com", "clauseId": "sha256:0xc2eb26d28ff4e229ff35917bd53339d82c1b30ec69435572a8872a4d7609c1dd", "source": "https://adr.example.org/clauses/dispute-resolution-service-rules", "catalog": "https://adr.example.org/.well-known/dispute-services.json" }, "returns": "https://example.com/api/returns", "contact": { "legal": "legal@example.com", "technical": "api-support@example.com" }, "api": "https://api.example.com/legal-context/v1" } ``` | Field | Type | Required | Description | |-------|------|----------|-------------| | termsFormat | string | OPTIONAL | Format or schema of the terms document. Known values: "markdown", "json", "plain", "pdf", "html". When absent, agents determine format from Content-Type header. | | atrHash | string | OPTIONAL | SHA-256 hash of the Agentic Transaction Record (ATR) — the ATR is the terms document itself (the standalone artifact of Section 4.3), and atrHash is its digest. 0x-prefixed hex (66 characters). See Level 2. | | acceptanceRequired | boolean | OPTIONAL | If true, counterparties MUST explicitly accept terms before transacting. See Level 3. Default: false. | | disputeResolution | object | OPTIONAL | Dispute resolution process. See Level 4. | | disputeResolution.method | string | OPTIONAL | The dispute resolution method (e.g., "Dispute Resolution Service Rules"). | | disputeResolution.jurisdiction | string | OPTIONAL | Governing jurisdiction. | | disputeResolution.contact | string | OPTIONAL | Contact for dispute filing. | | disputeResolution.clauseId | string | OPTIONAL | Content-addressed identifier of the dispute resolution clause. Format: sha256:0x followed by 64 hex characters. When present, the clause is verifiable. | | disputeResolution.source | string | OPTIONAL | URL where the dispute resolution clause text can be retrieved. Any resolvable URI. | | disputeResolution.catalog | string | OPTIONAL | URL of the dispute resolution provider's service catalog for programmatic clause generation. | | returns | string | OPTIONAL | URL of a returns or claims API/process. | | contact | object | OPTIONAL | Contact information for the service. | | contact.legal | string | OPTIONAL | Legal department contact. | | contact.technical | string | OPTIONAL | Technical support contact. | | api | string | OPTIONAL | URL of a legal context API for richer functionality. See Level 4. | The optional fields are a machine-readable INDEX of what the terms document says. They are not themselves terms. A provision appearing only in legal-context.json is advertising, not agreement; where a structured field and the terms document differ, the terms document controls. The field set is extensible. Implementations SHOULD ignore fields they do not recognize. ### 4.6 Serving Requirements The discovery document MUST be served over HTTPS. Clients SHOULD cache for no more than 24 hours. Services MAY include standard HTTP cache headers (Cache-Control, ETag, Last-Modified). --- ## 5. Levels of Trust (Advisory) ### 5.1 Level 1: Informational An agent can find the published terms at a known URL. Proceeding with a transaction after discovering the terms constitutes implicit consent — the browsewrap pattern. Its electronic-form validity rests on medium-neutrality under U.S. law (E-SIGN, 15 U.S.C. § 7001 et seq., and UETA § 7, with UETA § 14 validating contracts formed by automated electronic agents) and EU law (the E-Commerce Directive 2000/31/EC and eIDAS Regulation (EU) No 910/2014); whether the terms were presented conspicuously enough to bind is governed by case law and varies by jurisdiction. ### 5.2 Level 2: Provable The legal-context.json includes an atrHash — the SHA-256 digest of the **Agentic Transaction Record** (ATR), the terms document itself. This proves what the terms were and that they have not changed. If an atrHash is provided, the terms document MUST be byte-for-byte identical every time it is served. The hash may optionally be anchored to a blockchain, timestamp authority (RFC 3161), or content-addressed storage (IPFS, Arweave) to prove when the terms were published. ### 5.3 Level 3: Signed The counterparty digitally signs the terms (e.g., EIP-712 typed data signing). This adds cryptographic proof of intent: a specific party explicitly consented to specific terms at a specific time. When acceptanceRequired is true, the service requires explicit acceptance before transacting. ### 5.4 Level 4: Integrated The legal-context.json includes hooks to richer legal infrastructure: dispute resolution systems, escrow, multi-party agreement management, identity verification, compliance gating, returns processes, and access-controlled private terms. The api field provides the entry point. The disputeResolution object provides structured metadata including verifiable clause identifiers (clauseId), clause text sources (source), and provider service catalogs (catalog). --- ## 6. Transaction-Time Verification (Advisory) ### 6.1 Two Moments Discovery time: the agent visits legal-context.json to evaluate the service. Transaction time: the correct moment to fetch, verify, and save the terms. ### 6.2 Proposal-Phase Pattern Every major agentic commerce protocol has a two-phase flow (propose, then execute). At Level 2+, the atrHash SHOULD be included in the proposal phase to allow verification before payment. ### 6.3 Agent Verification Flow (Level 2+) 1. Receive the proposed atrHash from the server 2. Fetch the terms document from the URL provided 3. Compute SHA-256 of the downloaded document 4. Compare to the proposed atrHash — if mismatch, halt 5. Save the document locally 6. Proceed with payment 7. Receive receipt containing the same atrHash ### 6.4 Document Preservation Agents SHOULD save a copy of the terms at transaction time regardless of level. The service does not need to guarantee long-term availability. A hash without a document is a proof without evidence. --- ## 7. Private and Custom Terms (Advisory) ### 7.1 Ephemeral Link Pattern A seller can propose custom, private terms for a specific transaction. The server generates terms, computes the atrHash, includes both in the proposal with an ephemeral link. The agent downloads, verifies, saves. The link expires. Both parties have a copy. The hash is the proof. ### 7.2 Encrypted Persistent Storage For long-term private terms: hash the plaintext, then encrypt. The atrHash always identifies the content, not the encrypted artifact. Key rotation does not break the hash. --- ## 8. Content Storage (Advisory) Options: service-hosted (Level 1), content-addressed storage like IPFS/Arweave (Level 2+), third-party archival (Levels 2-4), on-chain storage (expensive, for high-value), encrypted storage (Level 4 private terms). --- ## 9. Security Considerations - Transport: MUST be served over HTTPS - Document integrity: atrHash provides Level 2+ verification - Terms versioning: atrHash in receipts is authoritative per-transaction - Ephemeral link security: unguessable URLs, short expiry, HTTPS - Privacy: legal-context.json is public; use ephemeral links for confidential terms - Rate limiting: SHOULD implement on all public endpoints Agent-side considerations (abridged): - Prompt injection: a policy engine SHOULD evaluate the structured fields of legal-context.json — bounded, typed values arriving over TLS — and SHOULD NOT let free-text prose in the terms body drive policy. Those fields are advertising; the terms document is the agreement. - Autonomous signing: gate signing behind a policy engine; escalate above a commitment threshold. - Display-versus-signed divergence: the document shown for human review MUST be byte-identical to the one whose hash is signed. - Replay across versions and signing-key compromise: record atrHash and timestamp on every acceptance. --- ## 10. IANA Considerations This specification REQUESTS registration of a well-known URI per RFC 8615. As of the date of this document no entry for legal-context.json exists in the IANA Well-Known URIs registry. - URI suffix: legal-context.json - Change controller: LCP Technical Steering Committee - Status: Intended — provisional registration sought; not yet filed Registration is not a precondition for conformance. --- ## 11. References ### Normative - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels - RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words - RFC 8615: Well-Known Uniform Resource Identifiers (URIs) ### Informative - RFC 3161: Internet X.509 PKI Time-Stamp Protocol - RFC 9421: HTTP Message Signatures - EIP-712: Typed structured data hashing and signing, September 2017 (Final) - ERC-3009: Transfer With Authorization, September 2020 (Draft; requires EIP-20 and EIP-712) - Fisher, D. and McCormack, B., "Identity, Trust, and the Legal Foundations of Agentic Commerce", March 2026 - Ryan, B., et al., "The 'Payment' HTTP Authentication Scheme" (Machine Payments Protocol), IETF Internet-Draft draft-ryan-httpauth-payment-01, March 2026 - Ryan, B., Moxey, J., Sproule, R., and Ragsdale, S., "Service Discovery for HTTP Payment Authentication", Internet-Draft draft-payment-discovery-00, June 2026 (paymentauth.org) - OpenAI, Stripe, and Meta, "Agentic Commerce Protocol", version 2026-04-17 - Google, "Universal Commerce Protocol", version 2026-04-08, April 2026 - Google, "Agent Payments Protocol (AP2)", v0.2, April 2026 (donated to the FIDO Alliance for community governance, April 2026) - Google, "Agent-to-Agent Protocol (A2A)", v1.0, March 2026 (current released revision v1.0.1, May 2026) - Model Context Protocol, spec version 2026-07-28 (stewarded under the Linux Foundation) - Visa, "Trusted Agent Protocol", October 2025 - Mastercard, "Verifiable Intent", v0.1-draft, February 18, 2026 (field schemas updated April 2026; contributed to the FIDO Alliance for community governance, April 2026) - Coinbase / x402 Foundation (Linux Foundation), "x402 Protocol", v2, December 2025 (contributed to the x402 Foundation under the Linux Foundation; Technical Charter March 2026)