Preservation profile pgd-wst-v1
Written to ETSI TS 119 511 V1.1.1 §6.4. Once published, this text does not change (OVR-6.4-13): changes go into the evidence policy, or into a new profile.
| Element (OVR-6.4-04) | Value |
|---|---|
| a) Identifier | https://trustbeat.eu/preservation/profile/pgd-wst-v1 |
| e) Storage model | WST, preservation service with storage |
| f) Preservation goal | PGD, preservation of general data: proof of existence and integrity of submitted hash values |
| d) Validity period | Active from 2026-10-11. No end date. Also covers earlier submissions from 2026-09-14 on whose batch has an RFC 4998 evidence record (see Scope). |
| c) Technical policies | Preservation evidence policy: https://trustbeat.eu/preservation/evidence-policy (version 1; versioned; the version in force at each date is public, OVR-6.4-14). No signature validation policy: the goal is not PDS. |
| g) Evidence formats | RFC 4998 Evidence Record (DER) |
| h) Specification | This document |
| i) Description | Below, in English. A Czech translation will follow; the English text takes precedence (OVR-6.5-02 by analogy). |
| j) Preservation scheme | None referenced |
Description
TrustBeat receives hash values only, never the data they were computed from. For each submitted hash it creates evidence that the hash existed at a certain time and has not changed since, and keeps that evidence valid for the preservation period.
- The proof covers the hash, not the data. It proves the existence of the data the hash was computed from only as long as the hash algorithm stays collision-resistant. Keeping the data, and computing the hash correctly, is the subscriber's responsibility (OVR-6.2-08, TS 119 511 §4.2).
- Evidence. Hashes received in the same 10-minute cycle are combined in a hash tree. The tree root is time-stamped by an EU qualified time-stamping authority. Each hash gets an RFC 4998 evidence record linking it to that time-stamp.
- Preservation period. 30 years from submission, on every plan, free included. A subscriber agreement may set a different period. Time-stamp renewal keeps the evidence verifiable for the whole period. SHA-256 may weaken within 30 years, and TrustBeat cannot re-hash the data: it holds only the submitted SHA-256 hash, which proves the original data only while SHA-256 stays collision-resistant (OVR-6.2-08). Protection against that needs new hash values from the subscriber (evidence policy §4).
- Renewal (augmentation). During the preservation period TrustBeat renews the evidence before it stops being verifiable, by RFC 4998 time-stamp renewal (§5.2), before the time-stamping certificate expires or its algorithms weaken. Hash-tree renewal (§5.3) needs the data re-hashed, which TrustBeat cannot do from a hash alone. When and how is stated in the evidence policy (OVR-6.5-07).
- End of the preservation period. When a record's period ends, TrustBeat notifies the subscriber by email and makes its export-import package available (hashes, evidence records and validation data). 30 days later TrustBeat removes the record's link to the subscriber and its metadata and stops serving its evidence, whether or not the package was downloaded; the batch's shared hash tree and time-stamps are deleted once every record of the batch has reached that point. Renewal stops at the end of the period (OVR-6.1-09). There is no deletion before the end of the period, also not on request (practice statement §6).
Scope
The profile covers every submission accepted from 2026-09-14 on whose batch has an RFC 4998 evidence record, and every submission after publication. 2026-09-14 is when TrustBeat began creating RFC 4998 evidence records; earlier submissions have none and are not covered. For a covered submission the preservation period counts from the submission date, also when it predates publication.
Supported operations (OVR-6.4-04 b, PRP-8.1)
TrustBeat uses its own REST API, documented at https://api.trustbeat.eu/docs, rather than the
TS 119 512 protocol (PRP-8.1-02 is a recommendation).
| Operation | TS 119 512 equivalent | Endpoint | Input formats | Output formats |
|---|---|---|---|---|
| Preserve | PreservePO |
POST /v1/anchor, POST /v1/anchor/batch |
A hash value, hex-encoded: SHA-256 only (64 hex characters; anything else is rejected). | Preservation object identifier (id) |
| Retrieve evidence | RetrievePO |
GET /v1/public/proof/{id}/evidence-record.ers |
Identifier | RFC 4998 evidence record (DER) |
GET /v1/anchor/{id}/proof |
Identifier | Additional output format: RFC 3161 token over an RFC 6962 Merkle root, with the inclusion proof (JSON) | ||
| Retrieve profiles | RetrieveInfo |
GET /v1/preservation/profiles |
None | This profile and every earlier one (JSON) |
| Retrieve profile and period of an object | (PRP-8.1-04) | GET /v1/anchor/{id}/status (preservation) |
Identifier | Profile identifier and end of the preservation period |
| Delete | DeletePO |
Not offered. A subscriber cannot delete a preservation object; TrustBeat deletes it only at the end of its preservation period (see Description). | ||
| Export-import package | (§7.16) | GET /v1/preservation/export (format: practice statement §5) |
Submission window (at most 31 days) | ZIP: manifest with hashes and preservation metadata, RFC 4998 evidence records with embedded validation data, Trusted Lists in force; every release recorded |
| Validate evidence (optional) | ValidateEvidence |
GET /v1/anchor/{id}/verify, POST /v1/public/verify |
Identifier, or hash + evidence | Validation result |
The RFC 6962 inclusion proof is an additional output format (OVR-6.4-04 b), not the preservation evidence: only the RFC 4998 evidence record is renewed.