Attested erasure
Make a person permanently unreadable in retained records, without deleting a row, and issue an attestation a third party can verify.
| Version | 2.0 — 15 September 2026 |
|---|---|
| Intended audience | Technical, security, integration and partner teams |
| Status | Technical description based on public information; implementation parameters to be confirmed |
Purpose and scope
Answer an erasure request without destroying the record that carries it. The declared identifying fields become unreadable everywhere at once, including in exports already sent and in backups the organisation can no longer write to; the rest of the row stays readable, so amounts, dates and totals continue to reconcile. Seal establishes that key material was destroyed and when; it does not determine whether the controller's legal erasure obligation is thereby discharged.
Operating principle
- The organisation declares its perimeter: its tables, and in each the fields that identify a person. The declaration is canonicalised, signed and timestamped.
- Exports pass through a library executed at the organisation. The declared fields are encrypted with a key that exists nowhere in full: a local half that never leaves the organisation, and a living contribution returned by Seal.
- On reading, the library requests the contribution again and recombines the key in memory. Seal receives only an opaque internal reference and sees no field.
- On an erasure request, Seal irreversibly destroys the key material specific to that reference. No recovery share ever covers that material.
- Seal issues an attestation carrying a twelve-character reference, readable aloud over the telephone, verifiable on a public page with no account and no contract.
Targeted threats
- Export or backup exfiltrated and exploited after the fact
- Record retained beyond the purpose that justified it
- Erasure declared by the organisation with no evidence a third party can test
- Mass extraction of a database through a diverted legitimate access
- Physical deletion made impossible by a referential integrity constraint
Components and responsibilities
| Component | Role |
|---|---|
| Verified organisation or publisher | Establishes its identity, channels or domains and manages authorised people. |
| User or approver | Presents a living proof or takes part in the authorisation according to policy. |
| Seal service | Assesses the verification elements required and returns a result limited to the use case. |
| Integrating system | Binds the Seal result to the exact action, applies business rules and keeps the required audit. |
| Verifier | Checks the result in context and does not interpret it as a guarantee of truth. |
Data and privacy
Seal receives no name, no email address, no postal address and no other field: it receives an opaque internal reference chosen by the organisation and returns a cryptographic contribution. The local half of the key is neither transmitted, nor hashed, nor sent in part. The material Seal retains is a seed per data subject and aggregate counters; destroying it is the operation itself. The exact fields, retention periods, logs, sub-processors and transfers must be confirmed in a data processing annex.
Expected security properties
- Irreversibility of the destruction, including for the service operator
- Separation of the key halves, one of which never leaves the organisation
- Survival of the record structure after the identity is erased
- Attestation verifiable by a third party with no account and no contractual relationship
- Unauthorised access detection by counting, without identifying the author
Limitations and assumptions
- The attestation records a technical fact and does not characterise it in law: it establishes neither that the data has become anonymous, nor that a legal erasure obligation is discharged. To date, no European, UK or Canadian supervisory authority has accepted or rejected key destruction as constituting legal erasure.
- The attestation does not establish that no copy was taken before the destruction, which no method can establish.
- Protection covers only the declared fields: identifying information left in free text, in an attachment or in an application log stays readable.
- The operation is irreversible; a request aimed at the wrong reference produces a permanent loss that neither the organisation nor Seal can repair.
- Statutory retention obligations may prohibit erasure within their period; some further require the legibility of the records retained.
- Losing the local half makes exports unreadable for everyone, including people who were never the subject of any request.
Items to confirm before integration
- API, request and response schemas, authentication and quotas
- Primitives, key lengths, derivation, entropy sources and applicable rotation
- Time windows, clock tolerance and behaviour on replay
- Envelope format, backward compatibility and migration procedure
- Data retained, retention periods, location and deletion
- Deferred destruction procedure, proof of execution and service continuity
- Penetration testing, independent cryptographic review and vulnerability disclosure procedure
Public references
- https://seal.lifaio.com/documentation
- https://seal.lifaio.com/aide/effacement
- https://seal.lifaio.com/effacement/verifier
Notice: this document describes the publicly communicated conceptual operation. It does not replace an API specification, cryptographic analysis or independent security audit.
UK patent applications pending: GB2619490.2 · GB2619948.9 · GB2620153.3 · GB2620211.9 · GB2620220.0 · GB2620253.1 · GB2620315.8 · GB2620629.2 · GB2621074.0 · GB2621382.7 · GB2622122.6 · GB2622135.8
