DSV (DocSignVault) — Electronic Signature Legal Note
Last updated: [DATE] (draft prepared 2026-10-08). Prepared for [COMPANY LEGAL NAME].
This note is informational. It is not legal advice and does not create an attorney-client relationship. E-signature law differs by country, state and document type, and changes. Senders must take advice from a qualified lawyer for their own documents. Statements about the law below are the drafter's general understanding and must be checked by counsel.
1. Short answer
DSV provides a simple (standard) electronic signature with a detailed audit trail and tamper-evidence. It does not provide an advanced or qualified electronic signature, and it does not verify who the signer is. In most commercial situations in the jurisdictions below, a simple electronic signature can be legally effective. Some document types need more, or cannot be signed electronically at all (section 5).
2. What DSV provides
| Element | What it is | What it supports |
|---|---|---|
| Consent to do business electronically | A separate screen the signer must accept before signing. Wording is "Consent text v1" in LEGAL_REVIEW_CHECKLIST.md (version string 2026-10-08.v1, stored with each consent). It covers agreement to electronic records, paper copies, withdrawal, scope, hardware/software needs, keeping a copy and updating contact details. | Evidence of consent where consumer e-sign consent rules apply; intent to sign electronically |
| Signature capture | Drawn, typed (several fonts) or uploaded image; initials auto-generated and editable | Intent to sign; the act of signing |
| Access control | Unique expiring link bound to one recipient, plus a one-time code sent to the email or phone the Sender entered | Reasonable link between the signer and the contact point the Sender chose. It does not prove the person's identity. |
| Audit trail | Events: sent, delivered, opened, code verified, pages viewed, each field completed, each photo uploaded, signed, countersigned, completed, downloaded. Each records UTC time, IP address, device/browser, and the email or phone used. | Attribution and a record of process |
| Certificate of Completion | Final page listing parties, timestamps, IPs, SHA-256 hash, template version, consent version, seal and timestamp details. It states plainly that DSV does not verify identity or ID authenticity. | A single record of the signing event |
| SHA-256 hash | Fingerprint of the completed document, printed on the certificate and stored | Integrity: any change changes the hash |
| PDF certificate seal | PAdES-style digital signature over the whole PDF; later edits make it show as invalid | Integrity and origin (the platform sealed it). Trust display in PDF readers depends on the certificate authority; see section 7. |
| RFC 3161 timestamp | A timestamp token from a public timestamp authority, embedded in the seal. The authority receives only a hash. If the authority is unreachable at sealing, sealing still completes without a token and the error is recorded. | Evidence of the time the document existed in that form |
| Verify page | Anyone can upload a PDF or enter a document ID to check authenticity and unchanged state | Independent integrity check |
| Immutability | Completed documents cannot be edited; changes are new linked amendments | Integrity |
| ID photos and face-with-ID photo (optional) | Stored and shown to the Sender; each becomes a stamped page in the PDF. No verification is performed by DSV. | Additional evidence the Sender may weigh. Not identity proofing. |
3. How each element supports attribution and integrity
Attribution (who signed) rests on: the Sender's choice of contact details; the link plus one-time code; the recorded IP and device; the signer's typed or uploaded identity details; and, where used, ID photos the Sender reviewed personally. If identity is likely to be disputed, a Sender may need stronger evidence (a witness, a notary, a qualified signature or independent identity verification). DSV does not offer these.
Integrity (the document did not change) rests on the hash, the seal and the timestamp. These show that the sealed file is unchanged since sealing. They do not show that the contents are legally valid.
Intent and consent rest on the separate consent screen, the explicit signing action and the audit log of fields completed.
4. Jurisdiction map
This table shows how a simple electronic signature is generally treated and what the DSV design maps to. [Counsel to verify each row, add local variants and confirm current law.]
| Jurisdiction | Law | Level DSV provides | Notes for counsel |
|---|---|---|---|
| United States (federal) | ESIGN Act (15 U.S.C. § 7001 et seq.) | Electronic signature meeting the general rule that a signature or record cannot be denied effect only because it is electronic | Requires intent to sign, consent to electronic business (the consent screen is designed for the consumer-consent elements), association of the signature with the record, and record retention and reproducibility. Exceptions exist (see section 5). |
| United States (states) | UETA (adopted in most states; New York uses its own Electronic Signatures and Records Act) | Same | State exceptions and extra rules vary. Check the governing-law state. |
| European Union | eIDAS Regulation (EU) 910/2014, Art. 25 | Simple electronic signature (Art. 3(10)). Not advanced (Art. 26) and not qualified (Art. 3(12)). | Art. 25(1): a signature must not be denied legal effect or admissibility solely because it is electronic or not qualified. Only a qualified signature has the equivalent effect of a handwritten signature by law (Art. 25(2)). National law may require form for some contracts. eIDAS 2.0 amendments (2024) should be reviewed. |
| United Kingdom | Electronic Communications Act 2000; UK eIDAS (retained) as amended by the Electronic Identification and Trust Services for Electronic Transactions Regulations 2016 | Simple electronic signature | Generally admissible and capable of satisfying signature requirements, subject to form rules. Law Commission guidance (2019) supports the view that electronic signatures satisfy statutory signature requirements generally. |
| Canada | PIPEDA Part 2 (federal) ("secure electronic signature" is a defined, higher level for specific federal uses); Uniform Electronic Commerce Act (UECA) and provincial e-commerce acts (for example Ontario Electronic Commerce Act, 2000; Quebec Act to establish a legal framework for information technology) | Electronic signature, not a "secure electronic signature" | Quebec has particular rules on technology-based documents and on language (French) for consumer contracts. Check Quebec separately. |
| Brazil | Medida Provisória 2.200-2/2001; Lei 14.063/2020 | Simple electronic signature (assinatura eletrônica simples). Not advanced and not ICP-Brasil (qualified) | Parties may agree to accept non-ICP-Brasil signatures (MP 2.200-2, Art. 10 §2). Lei 14.063/2020 sets levels for dealings with public bodies and health. A document needing ICP-Brasil or advanced level requires a different tool. |
| Australia | Electronic Transactions Act 1999 (Cth) and state and territory equivalents | Electronic signature meeting the method-reliability and consent tests | A method must be reliable or proven reliable, and the recipient must consent. Execution of deeds, witnessing and company documents have specific rules. Check Corporations Act s 127 for company execution. |
5. Documents that often need more, or cannot be signed electronically
Commonly (not universally) affected:
- Wills and codicils and some trusts: formal witnessing rules; electronic wills are allowed only in some places and by special process.
- Some real-estate deeds, conveyances and mortgages: witnessing, notarisation or land-registry requirements.
- Court documents, affidavits and sworn statements: court rules and oaths may require wet ink, notarisation or approved platforms. Note that the declaration wording under 28 U.S.C. § 1746 in the starter records form is not an affidavit.
- Some family-law documents (adoption, certain divorce and custody papers, powers of attorney in some places).
- Powers of attorney, guarantees and deeds in jurisdictions with formal execution or witness rules.
- Documents with statutory notices (for example some utility cancellations or product recall notices) and some consumer-credit agreements.
- Notarised or apostilled documents; documents where a counterparty or authority demands a qualified or ICP-Brasil signature.
- Age-verification and record-keeping documents such as the 18 U.S.C. § 2257 form: an electronic signature may be accepted, but the record-keeping, labelling and custodian duties are separate and are the Sender's responsibility.
The Sender must check. DSV does not screen document types and does not warn when a document is of a kind that needs more.
6. Limits to state clearly to Senders and Signers
- DSV does not verify identity or ID authenticity (no verification, OCR, face matching or liveness).
- A simple electronic signature is a weaker form of evidence than a qualified electronic signature in the EU.
- The seal proves the file is unchanged since sealing; it does not prove the document is lawful or enforceable.
- Starter templates are customizable, attorney-reviewable templates, never represented as valid in any jurisdiction.
- Machine translations are for convenience only. The controlling language version governs.
7. Seal certificate and timestamp: points for counsel
- Development uses a self-signed certificate. Before launch, DSV must obtain a document-signing certificate from an Adobe Approved Trust List (AATL) member so that readers can show the seal as trusted. Until then, the seal still reveals tampering but viewers may show an unknown signer.
- The public timestamp authority is a third party (DigiCert, see
SUBPROCESSORS.md). Counsel should consider reliance, availability and long-term validation (whether re-timestamping or LTV data should be added for records kept many years). - Hash algorithm and certificate key lengths should be reviewed periodically.
8. Checklist for counsel
- [ ] Confirm consent text v1 meets ESIGN § 7001(c) consumer-consent elements and equivalents (UETA, EU/UK consumer law, Canada, Brazil, Australia).
- [ ] Confirm the certificate-page wording (in
LEGAL_REVIEW_CHECKLIST.md) accurately describes what DSV does and does not do. - [ ] Decide how to describe the signature level in marketing and the product (words like "simple electronic signature"; no "legally binding everywhere").
- [ ] Confirm whether one-time code to email or SMS is adequate attribution for the intended customers, and whether to offer stronger options (witness, ID verification provider, qualified signature) later.
- [ ] Review the jurisdiction table (section 4) for accuracy and add EU member-state and US state specifics.
- [ ] Prepare a list of document types DSV should warn about in the product (section 5).
- [ ] Review long-term preservation: retention of the audit trail, certificate, timestamp token and the consent text version for the full retention period.
- [ ] Confirm how a Signer's consent withdrawal is recorded and handled.
- [ ] Confirm the approach to witnesses and countersigners.
- [ ] Review Sender-to-Signer governing-law and venue clauses in the starter templates (template choice is the Sender's; see Terms).
- [ ] Confirm that audit-trail IP and device collection is covered by the Privacy Policy and DPA.
- [ ] Confirm the trusted certificate (AATL) and timestamp authority are in place before launch.
- [ ] Confirm the evidence-export process if a Sender or Signer needs to prove a signature in court (certificate, hash, audit trail, timestamp token, photo access log).
9. Disclaimer
This document describes product features and general legal concepts for discussion with counsel. It is not legal advice, and no part of it should be given to Senders or Signers as a statement that a signature will be valid or enforceable in any place. [COMPANY LEGAL NAME] makes no such statement. Contact: [CONTACT EMAIL].