Legal Evidence
Web Resource Ledger (WRL) captures web pages and packages them as WACZ bundles (Web Archive Collection Zipped) -- open-format ZIP archives containing the full captured content, a file-level integrity manifest, a cryptographic signature, and an independent RFC 3161 timestamp. This page explains how those technical properties map to legal authentication requirements under the Federal Rules of Evidence and the EU eIDAS Regulation.
What a WRL capture proves
A verified WRL capture establishes three properties:
- Existence: the captured URL contained the recorded content at the time of capture.
- Integrity: no byte of that content has been modified since capture. Every artifact is covered by a SHA-256 hash, and the full bundle is covered by an Ed25519 signature.
- Timing: an independent Timestamp Authority (DigiCert) recorded the exact bundle hash at a specific UTC time using the RFC 3161 protocol. That timestamp is bound to this bundle and cannot be transferred to a different one.
For a full explanation of how verification works and what each check confirms, see Verification. For the cryptographic implementation details behind signing and timestamping, see the Security Whitepaper — Encryption section.
Federal Rules of Evidence
Electronically stored information (ESI) introduced at trial must be authenticated. Under Rule 901(a), a proponent must "produce evidence sufficient to support a finding that the item is what the proponent claims it is." Rule 901(b) provides non-exclusive examples of how authentication can be satisfied.
Rule 901(b)(9): Process or system
Rule 901(b)(9) allows authentication by "evidence describing a process or system and showing that it produces an accurate result." Courts have applied this provision to automated processes that capture and preserve digital content.
WRL's capture pipeline provides the technical foundation that supports a 901(b)(9) authentication argument:
- Automated pipeline: captures are performed by a headless browser process with no human operator involved in the capture itself. The process is deterministic and logged.
- Signed output: each WACZ bundle is signed with an Ed25519 key. A valid signature proves the bundle was produced by the operator who holds the signing key and has not been modified since.
- Independent timing: an RFC 3161 timestamp from DigiCert proves when the bundle hash was observed. Because the timestamp is cryptographically bound to the hash, it cannot be reused for a different bundle or backdated.
- Public verification: anyone can run
npx @w-r-l/verifyagainst the capture URL and independently confirm all checks pass, without relying on WRL's infrastructure for the decision itself.
The combination supports the argument that WRL is "a process or system" that produces accurate results -- the signed, timestamped WACZ is the output of that system.
Rule 902(14): Data copied from an electronic device
Rule 902(14) allows self-authentication of data copied from an electronic device, storage medium, or file where the proponent provides a written certification from a qualified person that the copy was generated by a process of digital identification -- specifically, a process that compares the hash value of the produced copy against the original.
Per the Advisory Committee Notes, "hash value comparisons" are the paradigmatic "process of digital identification" contemplated by Rule 902(14).
WRL computes SHA-256 hashes for every artifact at capture time and embeds them in the bundle manifest. When verification runs, it recomputes those hashes and compares them against the recorded values. A passing verification confirms the comparison succeeds.
Rule 902(14) still requires a written certification from a qualified person -- WRL provides the technical infrastructure (the hash records and the verification tooling) but does not itself provide the certifying declaration. That certification must come from the party introducing the evidence or a qualified expert.
Rule 902(13): Certified records
Rule 902(13) allows self-authentication of records generated by an electronic process or system using a written certification meeting the requirements of Rule 902(11) or (12).
WRL generates a certification PDF for every completed capture that has a signed WACZ bundle. The document describes the automated capture process, the operator's identity, the capture-specific integrity evidence (bundle hash, Ed25519 signature, RFC 3161 timestamp), and the verification outcome -- in a format designed to support a 902(13) foundation when combined with the WACZ bundle.
How to obtain the certification document:
- API:
GET /v1/captures/{captureId}/certificate-- returns a PDF with no authentication required. The PDF is signed with the operator's Ed25519 key; the signature is delivered in theX-Signature-Ed25519response header alongside theX-Signature-Key-Idheader identifying the signing key. - Web UI: Open a completed capture in the WRL dashboard and select "Download Certificate."
Important: WRL generates the certification document, but a qualified person must still adopt and sign the certification statement when introducing the document as evidence. WRL's certificate is designed to support a 902(13) foundation -- it does not itself satisfy the rule's requirements for a written certification from a qualified person. Consult qualified legal counsel before relying on this document in any proceeding.
Certification document contents
The certification PDF is generated deterministically from the capture record. It contains the following information:
| Field | Description |
|---|---|
| Capture ID | The unique WRL identifier for this capture (cap_...) |
| Captured URL | The URL that was captured |
| Capture timestamp | UTC time when the capture was submitted and when it completed |
| Operator identity | The system operator's name, postal address, contact email, system name and URL, and source code repository |
| Process description | A plain-language description of WRL's automated capture pipeline: headless browser, no human operator involvement, deterministic output |
| Bundle hash | SHA-256 hash of the WACZ bundle manifest (datapackage.json), covering all artifact hashes |
| Ed25519 signature | The operator's signature over the bundle hash, confirming the bundle was produced by the operator's key |
| RFC 3161 timestamp | The UTC time recorded by an independent Timestamp Authority (DigiCert) and bound to the bundle hash |
| Verification instructions | URLs and procedures for independently verifying the capture's integrity (verification page, CLI tool, public key endpoint) |
| Certificate signature | Ed25519 signature over the PDF bytes, delivered in the X-Signature-Ed25519 response header |
The document is designed for use alongside the WACZ bundle, not as a standalone substitute for it. Verification of the WACZ bundle remains the primary cryptographic assurance; the certification document provides the written description of process and system that supports a 902(13) argument.
Evidence foundation checklist
The table below maps common opposing-counsel challenges to the technical properties WRL provides. This is practical trial-preparation guidance, not a formal analysis of which rule applies in any given case -- that analysis follows from the rule mapping above.
| What opposing counsel will ask | How WRL addresses it |
|---|---|
| Who captured it? | The Ed25519 signature identifies the operator. The signing key maps to a publicly resolvable key at GET /.well-known/signing-key. |
| When was it captured? | An RFC 3161 timestamp from DigiCert records the UTC time. The timestamp is bound to this exact bundle and cannot be transferred or backdated. |
| Has it been altered? | SHA-256 hashes cover every individual artifact. The Ed25519 signature covers the full bundle manifest hash. Any modification breaks verification. |
| How do I verify it independently? | npx @w-r-l/verify <capture-url> runs all checks off-chain. The verifier resolves the signing key independently; it does not ask WRL whether the capture passed. |
| Is the capture process reliable? | The capture pipeline is automated, deterministic, and produces a signed, timestamped output for every run. Process documentation is available for review. |
| Is there a written description of the process? | GET /v1/captures/{captureId}/certificate returns a PDF describing the capture process, integrity evidence, and operator identity. Designed to support a 902(13) foundation alongside the WACZ bundle. |
eIDAS: Qualified electronic timestamps
The EU eIDAS Regulation (Regulation 910/2014/EU) establishes a legal framework for electronic signatures, seals, and timestamps across EU Member States. Article 41(2) provides:
"A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound."
This is a rebuttable presumption: courts must accept the time and data integrity as accurate unless the opposing party produces evidence to the contrary. The burden of proof shifts to the party challenging the timestamp.
Article 41(3) further provides that a qualified electronic timestamp issued by a qualified Trust Service Provider (TSP) in one Member State is recognized across all EU Member States.
Standard vs. qualified timestamps. Every WRL capture receives a standard RFC 3161 timestamp from DigiCert. Standard RFC 3161 timestamps provide strong cryptographic assurance but are not eIDAS-qualified. They do not trigger the Article 41(2) presumption. Only captures where the account has opted into a qualified TSA -- a TSP on the EU Trust List -- carry an eIDAS-qualified timestamp. Qualified timestamps are supported as an account-level opt-in, not applied to all captures by default.
| US (Federal Rules of Evidence) | EU (eIDAS Regulation) | |
|---|---|---|
| Authentication model | Proponent demonstrates reliability of process or system to the tribunal | Qualified TSP certification creates a statutory presumption of accuracy and integrity |
| What is presumed | Nothing is presumed; proponent must produce sufficient authenticating evidence | Accuracy of date/time and integrity of bound data are presumed (rebuttable) |
| Burden on challenger | No presumption to overcome; challenger disputes sufficiency of authentication evidence | Challenger must produce affirmative evidence to rebut the presumption |
| Geographic scope | Jurisdiction of the tribunal | Recognized across all EU Member States under Art. 41(3) |
| WRL coverage | All captures (standard RFC 3161 timestamps support 901(b)(9) arguments) | Qualified timestamps available as account opt-in; standard timestamps do not qualify |
WRL vs. traditional evidence preservation
The previous sections addressed the legal standards. This section and the next compare WRL's approach against the methods practitioners most commonly use today.
| Approach | Integrity proof | Time proof | Independent verification | Scalability |
|---|---|---|---|---|
| Screenshot + affidavit | Affiant's testimony that the screenshot was not altered | Affiant's testimony about when the screenshot was taken | None -- no method exists for a third party to confirm the screenshot matches the original page | Manual; one screenshot per URL per person |
| Web archive services | None provided to the requester -- the service controls the archive | The service's own records | The service's own confirmation -- no cryptographic mechanism available to third parties | High, but dependent on service availability and crawl scheduling |
| WRL | SHA-256 hashes + Ed25519 signature over the full WACZ bundle | RFC 3161 timestamp from an independent TSA (DigiCert) | Any party can run npx @w-r-l/verify against the capture URL and verify all checks independently |
Programmatic via API; authenticated captures available on demand |
WRL's verification is independent of WRL. The verifier resolves the signing key from the operator's public endpoint and validates the RFC 3161 timestamp against DigiCert's certificate chain. A third party can confirm authenticity without contacting WRL or taking WRL's word for anything.
Why screenshots and affidavits fall short
A screenshot is a raster image of what the operator saw at one moment. It carries no cryptographic proof of integrity: any image editor can alter pixels without detectable trace. Authentication depends entirely on the affiant's credibility and testimony -- a human assertion that is inherently subject to cross-examination on the affiant's competence, bias, and process.
Timestamps on screenshots (file system metadata, EXIF data, email headers) are controlled by the capturing device or service and are trivially adjustable. They do not involve an independent third party.
An affidavit does not describe the capture process in enough technical detail to satisfy a 901(b)(9) process-or-system argument. Courts have increasingly required more than testimony that "I took a screenshot" when authentication of web content is contested.
None of this means screenshots are inadmissible. In uncontested matters they often suffice. The gap appears when opposing counsel challenges authenticity and the proponent has no mechanism to respond beyond testimony.
How verification compares across services
The table below describes how verification works across different approaches. It focuses on the verifiable mechanism rather than the services offering it. No brand names are used because the relevant question for evidence purposes is the mechanism, not the vendor.
| Approach | How verification works |
|---|---|
| Open-standard signed archives (WRL) | SHA-256 hashes per artifact, Ed25519 signature over the bundle manifest, RFC 3161 timestamp from an independent TSA. Verifier is a separate source-available package that resolves the signing key independently and confirms the certificate chain. All verification data is embedded in the bundle. |
| Web archive services | Verification is typically the service's assertion that the archived copy matches the original capture. No cryptographic mechanism is provided to external parties to confirm independently. |
| Enterprise capture platforms | Approaches vary. Some provide hash-based integrity checks; fewer provide independent timestamp authorities. Verification typically requires access to the platform. |
| Browser extension tools | Capture is performed by the browser extension on the user's machine. Integrity depends on the extension's implementation; no independent timestamp is standard. Chain of custody depends on how the captured file is handled after capture. |
| Manual screenshots | No integrity proof. Authentication depends entirely on testimony. No independent timing mechanism. |
This page is for informational purposes only and does not constitute legal advice. The applicability of any legal standard depends on your jurisdiction, the specific proceeding, and the rules of the tribunal. Consult qualified legal counsel to evaluate how WRL evidence applies to your matter.