A digital signature provides cryptographic proof of explicit consent to specific terms. This section is advisory.
Overview
For explicit consent, the client cryptographically signs the terms — for example, using EIP-712 typed data signing or a similar standard. The signature creates a timestamped, attributable record: a specific party explicitly consented to specific terms at a specific time.
The service's side of the binding runs through the atrHash advertised at the moment of the transaction (Level 2). The service cannot retroactively claim a different document was in force, and the client cannot later claim different terms were offered. Combined, the record is explicit on the client side and evidentially locked on the service side. This is the digital equivalent of a signed contract — both parties bound to the same instrument.
Level 3 is opt-in, not the default
Services advertise acceptanceRequired: true only where explicit consent is wanted — typically for non-standard commitments, settlement agreements, confidential terms, or transactions whose value warrants an attributable acceptance record. Sub-dollar API traffic and other low-stakes flows generally remain at Level 1 or Level 2.
Level 3 deployments SHOULD integrate with a client-side policy engine that evaluates terms against the buyer's declared policy before any signature is produced. Autonomous acceptance above a configured commitment threshold SHOULD require human review. This standard specifies the cryptographic structure of the acceptance record; when to collect that record, and under what authorization controls, is a deployment decision driven by the buyer's policy.
How It Works
When acceptanceRequired is true in legal-context.json, the service signals that it requires explicit acceptance before transacting:
{
"terms": "https://example.com/terms/v3.md",
"atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
"acceptanceRequired": true
}
The flow:
Agent discovers that acceptanceRequired is true
Agent downloads the terms document
Agent verifies the atrHash (Level 2)
Agent's buyer-policy engine evaluates the terms against the principal's declared policy; signing thresholds may escalate to a human
Agent (or the human principal, if the policy escalates) signs the terms
The signature — binding a specific identity to a specific document at a specific time — is recorded
Transaction proceeds
What the Signature Proves
The combination of Level 2 (provable) and Level 3 (signed) creates a complete evidence chain:
- Evidence — What It Proves — atrHash — The exact document that was in effect — Digital signature — A specific party consented to that document — Timestamp — When the consent was given — Identity binding — Who consented (tied to a verifiable identity)
This is stronger than a traditional signature on paper. A paper signature can be forged. A digital signature on a hash-verified document cannot be repudiated — the signer either produced the signature or they did not.
Signing Standards
The LCP standard does not mandate a specific signing mechanism. Any digital signature standard is acceptable. Examples:
EIP-712 — Typed structured data hashing and signing (Ethereum ecosystem)
JSON Web Signatures (JWS) — Per RFC 7515 (web ecosystem)
XML Digital Signatures — Per W3C recommendation (enterprise ecosystem)
Qualified Electronic Signatures — Per eIDAS for EU regulatory compliance
The choice of signing standard depends on the ecosystem and regulatory requirements.
When Level 3 Is Appropriate
Level 3 is appropriate when the law or business relationship requires explicit, provable consent:
Regulated industries (financial services, healthcare, insurance)
High-value contracts
Agreements with specific legal requirements for signatures
Cross-border agreements where consent must be independently verifiable
Placeholder copy reproduced from legalcontextprotocol.org, the Legal Context Protocol, version 1.0 (Apache 2.0). Acme Travel will edit this page.
