Naming Conventions

This section is advisory.

Naming Conventions

The agentic commerce protocols are structurally different, so a single wire format cannot apply everywhere. The LCP standard defines three conventions depending on the field type.

String Fields: The lcp: Prefix

For string fields, use the lcp: prefix with a type indicator:

lcp:{type}:{value}

Self-identifying — any parser checks startsWith("lcp:"), then reads the type to know how to resolve the value.

Parsing rule: Split on the first colon to get lcp (the namespace). Split on the second colon to get the type. Everything after the second colon is the value (which may itself contain colons, e.g., in URLs).

Structured JSON: The legalContext Key

For structured JSON fields where the carrier admits a structured object (a session metadata map, a task metadata block, an extension object), use a standard key — "legalContext" — with type and value fields:

{
  "legalContext": {
    "type": "sha256",
    "value": "0x7f83b165...",
    "legalContextUrl": "https://example.com/atr/k7VdYqZw1uJmH6cnR0aA-g"
  }
}

The terms URL. value identifies the terms document; it does not locate one. Where the reference is a digest — every type but url — a counterparty that does not already hold the document cannot resolve the reference at all, and the obligation to make private or custom terms retrievable has nothing to act on. A digest reference therefore carries legalContextUrl alongside it, and a carrier admitting the reference but no locator is one this convention does not consider complete.

The locator is a locator and never the authority: a reader fetches it, hashes what it receives, and compares against value. A document that does not match is not the referenced terms, whatever the URL served. For that reason the URL MUST be https://, and a url-type reference needs no separate member, being its own locator.

One consequence is worth stating plainly, because independent implementations have shipped its violation: the locator moves with the reference. A permanent URL serves fixed bytes, and fixed bytes cannot hash to a per-transaction digest — so a reference minted per transaction carries an ephemeral link as its locator, never the discovery document's URL and never a static terms URL. A carrier that pairs a moving value with a fixed locator fails every fetch-hash-compare it invites, and it fails in the reader's tamper class rather than as anything a counterparty can recognize as a configuration error.

Where a host protocol's own naming convention governs the surrounding object, that convention wins over this spelling: the member is legal_context_url in a snake-case host, and a host that places the locator on a different object of its own has satisfied this rule as long as one document carries both and a reader can find them together. Two slots on one document MUST NOT disagree.

Raw Byte Fields

Where the carrier is a fixed-width byte string with no room for prefix or structure, the LCP reference is the raw atrHash bytes. The carrier's own conventions define how the value is interpreted; placement and length are specified in an external profile document, in the relevant illustration in Appendix B: Pattern Illustrations, or in the relevant per-protocol illustration.

MCP Resource URIs: The lcp:// Scheme

Where the carrier is an MCP resource URI scheme, deployments MAY use the lcp:// URI scheme to expose LCP records as readable resources. The lcp:// scheme is distinct from the lcp: prefix used in string fields above; the URI form is appropriate where the carrier expects a fully-qualified URI rather than a self-identifying string. See MCP Integration for indicative resource URI shapes such as lcp://legal-context/{domain} and lcp://agreement/{id}. The MCP stewards are invited to publish authoritative resource URI conventions.

Known Types

The type set is extensible and is not closed. Implementations SHOULD ignore types they do not recognize. Additional types MAY be defined by deployments; implementers are encouraged to publish type extensions in their own documentation rather than canonizing them in this standard.