Preservation service practice statement, version 1

Written to ETSI TS 119 511 V1.1.1 §6.1 (OVR-6.1-01..09) and ETSI EN 319 401 §6.1.

1. Policies and profiles (OVR-6.1-02, 6.1-03)

Preservation service policy. TrustBeat operates to the main policy of ETSI TS 119 511, OID 0.4.0.19511.1.1 ("policy for preservation services", §4.3.2), without the additional requirements for qualified preservation services (Annex A). A qualified status is not available for this goal: TS 119 511 Annex A note 2 reserves it for the preservation of qualified electronic signatures and seals. TrustBeat has not been assessed against this policy by a conformity assessment body; until it is, TrustBeat describes the service as designed to ETSI TS 119 511, not as conforming to it.

eIDAS. The time-stamps in the evidence are qualified electronic time-stamps (Article 41) issued by qualified trust service providers on an EU Trusted List under Regulation (EU) No 910/2014 (eIDAS), as amended by Regulation (EU) 2024/1183. The preservation service itself is not a qualified trust service under that Regulation: it is neither a qualified preservation service, which the Regulation provides only for qualified electronic signatures and seals (Articles 34 and 40), nor a qualified electronic archiving service.

Known deviation. TrustBeat does not meet PRP-8.1-11 and PRP-8.1-12 (deletion of stored preservation objects before the end of the preservation period); see §6.

Supported preservation profiles.

The current and all earlier profiles are listed at GET https://api.trustbeat.eu/v1/preservation/profiles and published at https://trustbeat.eu/preservation, each profile at its identifier. The profile references the preservation evidence policy (evidence-policy-v1.md), which states how evidence is created, renewed and validated in each period.

Scope. Only document anchors (POST /v1/anchor, POST /v1/anchor/batch) are preservation objects. Tamper-Evident Logs, AI decisions and Audit Trail use the same anchoring infrastructure but are not preservation objects under this statement. A document anchor is a preservation object when it was submitted from 2026-09-14 00:00 UTC onwards and its batch has an RFC 4998 evidence record; that is when TrustBeat began creating such records. An anchor carries its profile and the end of its preservation period from the moment it is assigned, and never changes profile (GET /v1/anchor/{id}/status, field preservation). Earlier anchors keep their existing proofs but are not covered.

2. How the preservation goal is achieved (OVR-6.1-04)

The goal is PGD: proof that a submitted hash value existed at a given time and has not changed since, kept verifiable for the preservation period.

1. Submission. The subscriber computes the SHA-256 hash of its data and submits only the hash. TrustBeat never receives, stores or sees the data. Anything other than a 64-character hexadecimal SHA-256 value is rejected. The response carries the preservation object's identifier.
2. Evidence. Hashes are collected in batches at fixed 10-minute boundaries. Each batch's hashes form an RFC 4998 hash tree whose root is time-stamped by an EU qualified time-stamping authority (§4). Validation data for the time-stamp (certificate path, OCSP response or CRL) is collected and embedded in a copy of the token, leaving the issued token unchanged. Each hash then has an RFC 4998 evidence record. Details: evidence policy §1.
3. Preservation period. 30 years from submission, on every plan including the free plan, unless a subscriber agreement states otherwise. Stored per object as preserve_until.
4. Renewal. Before the last time-stamp in a record stops being verifiable (90 days before its signing certificate expires, or earlier if TS 119 312 assesses its algorithms as weakening), TrustBeat adds an RFC 4998 time-stamp renewal (§5.2). One renewal time-stamp covers many batches. Evidence policy §4.
5. Limits of a hash-only service (OVR-6.2-08). The evidence proves the existence of the hash. It proves the existence of the data only while SHA-256 stays collision-resistant, and only if the subscriber kept the data and computed the hash correctly. TrustBeat cannot re-hash data it never received, so it offers no hash-tree renewal (RFC 4998 §5.3) in profile pgd-wst-v1. If SHA-256 is assessed as weakening, TrustBeat will notify subscribers by email and state in a new evidence policy version whether and how new hash values can be submitted.
6. Validation. Evidence records are standard RFC 4998 and can be validated without TrustBeat software (for example with EU DSS); trust anchors are the EU Trusted Lists. TrustBeat keeps signed copies of every version of these lists it loads, so a TSA's qualified status on a past date can still be shown. Evidence policy §5.

Protocol. TrustBeat offers its own REST API (https://api.trustbeat.eu/docs), not the TS 119 512 protocol (PRP-8.1-02 is a recommendation). The profile maps each operation to its TS 119 512 equivalent.

3. Availability of submitted data objects and evidence (OVR-6.1-05)

The submitted data object is the hash value. TrustBeat stores it, the batch's hash tree, the time-stamp tokens as issued, the copies with validation data, the renewals and the Trusted List snapshots, for the whole preservation period.

• Retrieval. At any time during the preservation period:
  • the subscriber, authenticated, retrieves the evidence record, proof and status of its own objects and the export-import package (§5);
  • anyone holding an object's identifier retrieves its evidence record and proof from the public endpoints (GET /v1/public/proof/{id}/evidence-record.ers), so a relying party can verify without an account. The identifier is the only key; the hash reveals nothing about the data.
• Storage. One PostgreSQL database on a dedicated server at Hetzner Online GmbH, Germany. Evidence is built on request from the stored tree and tokens; the stored tokens are never modified.
• Backups. Daily, encrypted before they leave the server, stored in a second EU country (Scaleway, France) in storage that cannot be overwritten or deleted from production; integrity and restore are tested: integrity weekly, a full restore every three months. Recovery point: up to 24 hours. If the database were lost, submissions accepted since the last daily backup, and their evidence, could be lost; the subscriber would hold identifiers that no longer resolve and would need to submit those hashes again (with a later time). Reducing this to minutes is planned.
• Copies held by the subscriber. The subscriber can download its evidence records and export-import packages at any time and is advised to keep them with the data. An evidence record remains verifiable without TrustBeat until its last time-stamp expires; renewed records must be downloaded again after a renewal.
• Availability target. No contractual availability level for the free, Developer and Business plans; an Enterprise subscriber agreement may set one. A failure of the time-stamping authority delays evidence but never loses an accepted submission: hashes stay pending until a batch is time-stamped, by the fallback TSA if needed.

4. External organisations (OVR-6.1-06, EN 319 401 §6.1)

The TSAs and Trusted List operators are relied on only through what they publish and sign; their statements can be checked independently of TrustBeat. No external organisation has access to preservation objects, except as the hosting and backup providers of encrypted or stored data.

5. Export-import package (OVR-6.1-07, 6.1-08)

How to request one. The subscriber requests a package itself, at any time during the preservation period, without contacting TrustBeat: GET https://api.trustbeat.eu/v1/preservation/export?from=<time>&to=<time>, authenticated with the account's API key or portal session, or with the Export package button in the portal (https://trustbeat.eu/preservation-export), which calls the same endpoint. One package covers the account's preservation objects submitted in a window of at most 31 days; longer periods are exported as consecutive windows. A subscriber that cannot use either can ask hello@trustbeat.eu from the account's email address.

How it is produced. Format trustbeat-export-import-v1:

• a ZIP, not encrypted (it contains hashes and public evidence only; it travels over TLS);
• manifest.json: selection, profiles, and per object the hash, submission and anchoring times, client_ref, profile and end of preservation period, with the SHA-256 and size of every other file;
• objects/<id>.ers: the RFC 4998 evidence record with embedded validation data and all renewals, byte-identical to the public endpoint;
• trusted-lists/: the signed EU List of Trusted Lists and each relevant national list in force at each evidence time-stamp;
• the same inputs give the same bytes.

Packages are released only to the authenticated account, for its own objects. Every release is recorded before it is sent (time, selection, counts, SHA-256 and size of the package); without a record no package is sent, and records are never changed or deleted (OVR-7.16-04). TrustBeat does not transfer packages to another preservation service; the subscriber passes them on.

6. Deletion and the end of the preservation period (OVR-6.1-09)

No deletion during the preservation period. Neither the subscriber nor TrustBeat deletes a preservation object before its preservation period ends; TrustBeat does not delete on request either. This deviates from TS 119 511 PRP-8.1-11 ("a preservation service with storage shall allow to delete stored POs") and PRP-8.1-12. The reason: each evidence record is built from all the hashes of its batch, which belong to many subscribers. Removing one hash would make the evidence records of every other object in that batch unverifiable or would require altering stored evidence, which the service never does. The hash itself reveals nothing about the data, and the subscriber can make the evidence useless to itself simply by discarding the data.

Closing an account does not end the preservation period. The account's objects stay preserved and renewed until their periods end, and remain retrievable by identifier from the public endpoints. After closure there is no authenticated access and no notifications; the subscriber should download an export-import package before closing.

At the end of the preservation period of an object:

1. TrustBeat stops renewing its evidence.
2. TrustBeat notifies the subscriber by email at the account's address and makes the export-import package of the object available.
3. 30 days later TrustBeat deletes the object's link to the account and its metadata (client_ref, description), whether or not the package was downloaded, and stops serving its evidence. The hash, hash tree and time-stamps of its batch are shared with the other objects of the batch and stay until the last of them has reached this step; then they are deleted too. Every deletion is logged.

The first preservation periods end in 2056.

7. Termination of the service (EN 319 401 §6.1, OVR-7.12)

If TrustBeat stops the service, it follows its termination plan:

• at least 6 months' notice by email to every account and on trustbeat.eu (as fast as possible if the termination is unplanned);
• preservation and renewal continue until the stop date, and exports stay open;
• shortly before the stop date, a last time-stamp renewal of all evidence, with the qualified TSA whose certificate expires latest, and a final export-import package for every account;
• the public evidence and verification endpoints stay online for 12 months after the stop date;
• no successor is promised; a transfer to another preservation service happens only with notice to each subscriber, who may refuse;
• arrangements ensure the plan can be carried out, and its costs covered, even if the managing director cannot act or the company is insolvent.

After TrustBeat stops, a subscriber keeps its evidence verifiable beyond the last time-stamp by having the evidence record time-stamped again elsewhere.

8. Management of this statement (EN 319 401 §6.1)

• Approval. This statement, the profiles and the evidence policy are approved by TrustBeat's managing director (jednatel), who has final authority over the practices of the service and ensures they are implemented.
• Review. At least once a year, and whenever a profile, the evidence policy, an external organisation in §4 or the service's infrastructure changes materially.
• Changes. Registered subscribers are notified by email at least 14 days before a material change takes effect, as in the terms of service. The revised statement is published once approved. Every version stays available with the dates it was in force.
• Publication. At https://trustbeat.eu/preservation/practice-statement, alongside the profiles and the evidence policy (https://trustbeat.eu/preservation) and the terms of service (https://trustbeat.eu/terms).