Consent Attestation

Every consent certificate generated by eConsent includes a cryptographic attestation --- a structured dataset that proves what the consumer saw, how they interacted with it, and when the consent event occurred. This attestation is the evidentiary foundation that makes eConsent certificates defensible in litigation and audits.

What is attestation

Attestation is the process of collecting, hashing, and storing multiple independent pieces of evidence about a consent event. Unlike a simple timestamp or IP log, eConsent’s attestation ties together:

• What was on the page (content hashes and DOM snapshot)
• What the consumer did (interaction chain)
• What was visible (viewport and visibility proof)
• When it happened (server-side timestamps)
• Who the consumer is (extracted form data)

All of this data is cryptographically linked and stored across multiple redundant storage layers.

Data captured in attestation

SHA-256 content hashes

eConsent computes SHA-256 hashes of multiple page elements at the moment of consent:

Hash target	Purpose
Consent disclosure text	Proves the exact wording shown to the consumer. Matches against registered consent templates.
Full page content	Captures the entire rendered page, including surrounding context.
Form field values	Hashes the submitted form data (phone, email, name) for integrity verification.
Partner disclosure	If multiple parties are named in the disclosure, their names are individually extracted and hashed.

{
  "hashes": {
    "disclosure": "a3f2b8c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1",
    "pageContent": "b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5",
    "formData": "c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
  }
}

Note

SHA-256 is a one-way cryptographic hash function. It is computationally infeasible to alter the original content and produce the same hash. If any character in the disclosure changes, the hash changes completely.

Visibility proof

The attestation includes proof that the consent disclosure was actually visible to the consumer at the time of interaction:

{
  "visibility": {
    "disclosureVisible": true,
    "disclosureInViewport": true,
    "disclosureDimensions": { "width": 580, "height": 42 },
    "disclosurePosition": { "top": 412, "left": 30 },
    "viewportSize": { "width": 1440, "height": 900 },
    "scrollPosition": { "x": 0, "y": 380 },
    "cssProperties": {
      "display": "block",
      "visibility": "visible",
      "opacity": "1",
      "fontSize": "14px",
      "color": "#333333",
      "backgroundColor": "#FFFFFF"
    }
  }
}

This data proves that the disclosure was not hidden via CSS, positioned off-screen, or rendered at zero dimensions.

Interaction chain

The attestation records the sequence of consumer interactions leading to the consent event:

{
  "interactionChain": [
    {
      "type": "scroll",
      "timestamp": 1711900200000,
      "position": { "y": 380 }
    },
    {
      "type": "click",
      "timestamp": 1711900205000,
      "target": "input#tcpa-checkbox",
      "checked": true
    },
    {
      "type": "input",
      "timestamp": 1711900210000,
      "target": "input#phone",
      "valueHash": "d6e7f8..."
    },
    {
      "type": "submit",
      "timestamp": 1711900215000,
      "target": "form#lead-form"
    }
  ]
}

This chain demonstrates that the consumer actively engaged with the page --- they scrolled to the disclosure area, checked the consent box, filled in their information, and submitted the form. This counters claims of bot activity or accidental submission.

Page structure

A complete DOM snapshot is captured at the moment of consent, preserving:

• The full HTML structure of the page
• All visible text content
• Element positions and computed styles
• Image references and alt text
• Form field states (checked, selected, filled)

This snapshot can be used to reconstruct exactly what the consumer saw, independent of the session replay recording.

Three storage layers

eConsent stores attestation data across three independent storage layers for redundancy and durability:

PostgreSQL (Primary)

The structured attestation data (hashes, metadata, consumer identity, timestamps) is stored in the primary PostgreSQL database. This supports fast queries, verification API lookups, and dashboard access.

Amazon S3 (Archive)

The complete attestation payload, including the full DOM snapshot, is stored as an immutable object in S3. S3 versioning is enabled, preventing overwrite or deletion. This serves as the long-term archival layer.

Amazon EFS (Recording)

Session recordings (rrweb data) and MP4 conversions are stored on EFS for high-throughput read/write access during the active retention period. Recordings are referenced by the certificate and can be replayed alongside the attestation data.

Tip

The three-layer storage architecture means that even if one storage system experiences an outage, the attestation data remains available from the other layers. S3 in particular provides 99.999999999% (11 nines) durability.

Storage lifecycle

Phase	PostgreSQL	S3	EFS
Capture	Certificate record created with attestation metadata	Full attestation payload and DOM snapshot uploaded	rrweb recording data written
Active	Serves verification API queries and dashboard access	Immutable archive, versioning enabled	Serves session replay and MP4 conversion
Retained	Certificate remains queryable	Archive persists for full retention period	Recording retained per property settings
Expired	Marked for cleanup after retention period	Object lifecycle policy archives to Glacier or deletes	Recording files cleaned up by cron job

Reading attestation on the certificate page

Every consent certificate has a public URL that displays the attestation in a human-readable format. The certificate page includes:

Summary section

• Certificate ID and generation timestamp
• Consumer identity (name, email, phone as captured)
• Consent status (active or revoked)
• WCAG accessibility level (AAA, AA, or Fail)
• Language detected in the disclosure

Evidence section

• Disclosure text as captured, with SHA-256 hash displayed
• Session replay embedded player showing the consumer’s full interaction
• Interaction chain timeline showing scroll, click, input, and submit events
• Visibility proof confirming the disclosure was on screen

Technical section

• All SHA-256 hashes for disclosure, page content, and form data
• DOM snapshot available for download
• Raw attestation JSON for programmatic processing
• Storage references to S3 and database records

Verifying attestation programmatically

Use the Verification API to retrieve attestation data for a certificate:

Node.js

async function getAttestation(certificateId) {
  const response = await fetch(
    'https://api.econsent.org/api/verify/certificate-info',
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${process.env.ECONSENT_API_TOKEN}`,
      },
      body: JSON.stringify({
        certificate_id: certificateId,
        company_id: process.env.ECONSENT_COMPANY_ID,
      }),
    }
  );

  const result = await response.json();

  return {
    certificateId: result.certificate_id,
    disclosureHash: result.disclosure_hash,
    pageHash: result.page_hash,
    visibility: result.visibility,
    interactionChain: result.interaction_chain,
    accessibility: result.accessibility,
    language: result.language,
    createdAt: result.created_at,
  };
}

Python

import os
import requests

def get_attestation(certificate_id):
    response = requests.post(
        'https://api.econsent.org/api/verify/certificate-info',
        headers={
            'Content-Type': 'application/json',
            'Authorization': f'Bearer {os.getenv("ECONSENT_API_TOKEN")}',
        },
        json={
            'certificate_id': certificate_id,
            'company_id': os.getenv('ECONSENT_COMPANY_ID'),
        },
    )
    result = response.json()

    return {
        'certificate_id': result.get('certificate_id'),
        'disclosure_hash': result.get('disclosure_hash'),
        'page_hash': result.get('page_hash'),
        'visibility': result.get('visibility'),
        'interaction_chain': result.get('interaction_chain'),
        'accessibility': result.get('accessibility'),
        'language': result.get('language'),
        'created_at': result.get('created_at'),
    }

Attestation integrity

The attestation system is designed so that no single party --- including eConsent --- can alter the evidence after capture:

• SHA-256 hashes are computed at capture time and cannot be reversed or forged.
• S3 versioning prevents overwriting or deleting archived attestation objects.
• Timestamps are server-side UTC, not client-provided.
• Interaction chains are derived from the rrweb recording, which captures real DOM events.
• Multi-layer storage means tampering with one layer leaves the other layers intact as a cross-reference.

Caution

eConsent’s attestation provides strong evidence of consent but is not a substitute for legal advice. Consult with your legal team to ensure your consent process meets all applicable regulatory requirements.

Next steps

• Consent Certificates. Certificate format and generation process
• Session Replay. How rrweb recordings are captured and stored
• Consent Versioning. SHA-256 template matching
• Accessibility Compliance. WCAG 2.1 checks included in attestation
• TCPA Compliance Guide. Using attestation for TCPA defense
• Retention Management. Storage lifecycle and retention periods