{"id":"profile-pds-wst-v1","title":"Preservation profile pds-wst-v1","version":1,"status":"in_force","in_force_from":"2026-10-29","url":"https://trustbeat.eu/preservation/profile/pds-wst-v1","series_url":"https://trustbeat.eu/preservation/profile/pds-wst-v1","current":true,"markdown":"# Preservation profile `pds-wst-v1`\n\nWritten to ETSI TS 119 511 V1.2.1 (2025-10) §6.4. Once published, this text does not change (OVR-6.4-13): changes\ngo into the evidence policy or the signature validation policy, or into a new profile.\n\n| Element (OVR-6.4-04) | Value |\n|---|---|\n| **a) Identifier** | `https://trustbeat.eu/preservation/profile/pds-wst-v1` |\n| **e) Storage model** | **WST**, preservation service with storage |\n| **f) Preservation goal** | **PDS**, preservation of digital signatures: proof of existence of digital signatures and of their validation data, and of the digests of the data they sign |\n| **d) Validity period** | Active from **2026-10-29**. No end date. |\n| **c) Technical policies** | Preservation evidence policy: `https://trustbeat.eu/preservation/evidence-policy` (version 2 and later; the version in force at each date is public, OVR-6.4-14). Signature validation policy: `https://trustbeat.eu/preservation/signature-validation-policy` ([version 1](signature-validation-policy-v1.md)). |\n| **g) Evidence formats** | RFC 4998 Evidence Record (DER) over the Preservation Evidence Object (PEO, below) |\n| **h) Specification** | This document |\n| **i) Description** | Below, in English. A translation, if any, is informative; the English text takes precedence (OVR-6.5-02 by analogy). |\n| **j) Preservation scheme** | None referenced |\n\n## Description\n\nThe subscriber keeps its signed files. TrustBeat preserves **the signatures in them**, the validation\ndata needed to validate those signatures later, and the digests that bind each signature to the data it\nsigns. **The signed file itself is never sent to TrustBeat.**\n\n- **Submission without the file.** The subscriber runs TrustBeat's extractor (`trustbeat-signature`), a\n program on its own computer. The extractor reads a signed file, takes out each signature, computes the\n digests of the signed data and of the whole file, checks that the signatures cover the data they claim\n to cover, and sends only that (the *submission*) to TrustBeat. TS 119 511 allows a detached signature\n with only a hash of the signed data (OVR-9.3-05). The extractor is open source (MIT) and published, with\n its releases, at ; how to obtain and check it is in\n the practice statement.\n- **Checks by TrustBeat.** TrustBeat re-derives, from inside each signature, the digests the submission\n declares and rejects the submission if they differ. It validates each signature with EU DSS under the\n signature validation policy, collects the certificates, OCSP responses and CRLs needed to validate it\n (OVR-9.3-01) and records the result as found on the day. A signature is preserved whatever the result:\n the record says what the validation found, it does not decide whether a signature is acceptable.\n- **Preservation Evidence Object (PEO).** All of it — the signatures byte for byte, the declared digests,\n the validation data, the validation result, and references to the EU Trusted Lists in force — goes into\n one canonical JSON document per submission, the PEO. TrustBeat stores the PEO.\n- **Evidence.** The PEO's SHA-256 digest is time-stamped in the same way as a document anchor: combined\n with other digests of the same 10-minute cycle in an RFC 4998 hash tree whose root is time-stamped by an\n EU qualified time-stamping authority. The resulting RFC 4998 evidence record proves that the PEO, and so\n each signature and its validation data, existed at that time and has not changed since.\n- **What is proven about the signed data.** The evidence covers the signatures and the digests of the\n signed data, not the data. It extends to the signed data only while the hash algorithms of the\n signatures and of the declared digests stay collision-resistant, and only for the data the subscriber\n kept. The digests are computed by the extractor on the subscriber's side: TrustBeat cannot check that\n they were computed from the real file (OVR-9.3-07, 6.2-08).\n- **Preservation period.** **30 years from submission**, on every plan. A subscriber agreement may set a\n different period. Time-stamp renewal keeps the evidence verifiable for the whole period.\n- **Renewal (augmentation).** As for document anchors: RFC 4998 time-stamp renewal (§5.2) before the last\n time-stamp stops being verifiable. Because TrustBeat holds the PEO, it can also renew the hash tree\n (§5.3) by re-hashing the PEO with a stronger algorithm; the PEO already carries SHA-512 and SHA3-512\n digests of the signed file for that case. When and how: evidence policy §4 and §8 (OVR-6.5-07).\n- **Missing validation data (OVR-6.2-06).** If some validation data cannot be obtained (for example an\n OCSP responder does not answer), the signatures are preserved anyway and the PEO lists what is missing.\n The submission is not refused.\n- **End of the preservation period.** As for document anchors: TrustBeat notifies the subscriber and\n makes the record's package available; **30 days later** it deletes the PEO, the record's metadata and\n its link to the subscriber, and stops serving its evidence. Renewal stops at the end of the period\n (OVR-6.1-09). Before that, the subscriber can delete a record at any time (below).\n\n## Accepted signatures (OVR-6.4-04 b, OVR-9.3-06, OVR-9.3-08)\n\n| Container (file the subscriber holds) | Signatures taken out | Signed data bound by |\n|---|---|---|\n| **PAdES** (PDF) | Each signature dictionary's `/Contents` (detached CAdES), across incremental updates; document time-stamps | digest of the `/ByteRange`; whether the signature covers the whole file |\n| **CAdES** detached (`.p7s` + data) | The CMS `SignedData` | `messageDigest` of each signer |\n| **CAdES** enveloping (`.p7m`) | A copy of the CMS with the encapsulated content removed (marked *content-detached*) | `messageDigest` of each signer |\n| **XAdES** detached, enveloped, enveloping | `ds:Signature` (with inherited namespace declarations added; for enveloping, without the signed `ds:Object`, marked as such) | `ds:Reference` digests; canonical `SignedInfo` digest |\n| **ASiC-E**, **ASiC-S** with XAdES or CAdES | Every signature file, every `ASiCManifest`, container time-stamps | references / manifest entries; digest of every data file |\n\nNot accepted in this profile (the extractor refuses the file and says why): JAdES; files without a\nsignature; signed data that no longer gives the digest inside its signature; detached signatures or\ncontainers whose signed data is missing; XML with a DOCTYPE, XML transforms other than enveloped-signature,\nC14N 1.0 / 1.1 / exclusive, base64 and the XPath patterns that remove signatures; encrypted PDFs; signers\nwithout signed attributes. A PDF changed after its last signature is accepted: the record states which\nsignatures do not cover the whole file. **One submission per signed file**, with at most 100 signatures,\n100 time-stamps and 10 000 data objects.\n\n**Hash functions of the declared digests (OVR-9.3-06).** Every file and data object: **SHA-256, SHA-512\nand SHA3-512**, all three, hexadecimal. The digests inside a signature use whatever algorithm the signature\nuses, as long as the signature validation policy can process it. TrustBeat checks every digest's identifier\nand length (OVR-9.3-08) and treats the declared digests as general data (OVR-9.3-07).\n\n**A file signed again later is a different file.** A record covers the signatures the file had when it was\nsubmitted. If the file is signed again afterwards, preserve it again after its last signature.\n\n## Supported operations (OVR-6.4-04 b, PRP-8.1)\n\nTrustBeat uses its own REST API, documented at `https://api.trustbeat.eu/docs`, rather than the\nTS 119 512 protocol (PRP-8.1-02 is a recommendation).\n\n| Operation | TS 119 512 equivalent | Endpoint | Input | Output |\n|---|---|---|---|---|\n| Preserve | `PreservePO` | `POST /v1/signature-preservation` | Submission JSON (format `trustbeat-signature` submission v1), produced by the extractor | Preservation object identifier (`id`), status |\n| Retrieve status | `RetrieveInfo` (per object) | `GET /v1/signature-preservation/{id}` | Identifier | Status (`pending` → `anchored` → `preserved`), signatures with the validation results, profile, end of the preservation period, evidence record link |\n| List | `Search` | `GET /v1/signature-preservation` | — | The subscriber's records |\n| Retrieve evidence | `RetrievePO` | `GET /v1/public/proof/{id}/evidence-record.ers` | Identifier | RFC 4998 evidence record over the PEO (DER) |\n| Retrieve preserved object and evidence | `RetrievePO` | `GET /v1/signature-preservation/{id}/package` | Identifier | Export-import package (below) |\n| Retrieve profiles | `RetrieveInfo` | `GET /v1/preservation/profiles` | — | This profile and every other one (JSON) |\n| Validate evidence | `ValidateEvidence` | `POST /v1/signature-preservation/{id}/verify` | Identifier + a submission of the file presented now | Verification report (JSON, or PDF with `?format=pdf`) |\n| Delete | `DeletePO` | `DELETE /v1/signature-preservation/{id}?confirm={id}` | Identifier, repeated | Deletion confirmation. Removes the PEO, the signatures and the metadata, and stops serving the evidence; the PEO's digest stays in the shared hash tree. Final. Logged; the account is emailed (practice statement §6). |\n\n**Export-import package (§7.16).** `GET /v1/signature-preservation/{id}/package`, one per record: a ZIP with\nthe PEO exactly as stored, every preserved signature, `ASiCManifest` and time-stamp in its native format,\nthe certificates, OCSP responses and CRLs, the RFC 4998 evidence record once ready, the signed EU Trusted\nLists the PEO refers to, a `manifest.json` with the SHA-256 of every file, and a `README.txt` with the\nverification steps. Format and verification: practice statement §5.\n\n**Verification without TrustBeat.** The package and the original file can be verified offline with the\nextractor (`trustbeat-signature verify --package `) or with standard tools, step by step\n(practice statement §2.3).\n","html":"

Preservation profile pds-wst-v1

\n

Written to ETSI TS 119 511 V1.2.1 (2025-10) §6.4. Once published, this text does not change (OVR-6.4-13): changes\ngo into the evidence policy or the signature validation policy, or into a new profile.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Element (OVR-6.4-04)Value
a) Identifierhttps://trustbeat.eu/preservation/profile/pds-wst-v1
e) Storage modelWST, preservation service with storage
f) Preservation goalPDS, preservation of digital signatures: proof of existence of digital signatures and of their validation data, and of the digests of the data they sign
d) Validity periodActive from 2026-10-29. No end date.
c) Technical policiesPreservation evidence policy: https://trustbeat.eu/preservation/evidence-policy (version 2 and later; the version in force at each date is public, OVR-6.4-14). Signature validation policy: https://trustbeat.eu/preservation/signature-validation-policy (version 1).
g) Evidence formatsRFC 4998 Evidence Record (DER) over the Preservation Evidence Object (PEO, below)
h) SpecificationThis document
i) DescriptionBelow, in English. A translation, if any, is informative; the English text takes precedence (OVR-6.5-02 by analogy).
j) Preservation schemeNone referenced
\n

Description

\n

The subscriber keeps its signed files. TrustBeat preserves the signatures in them, the validation\ndata needed to validate those signatures later, and the digests that bind each signature to the data it\nsigns. The signed file itself is never sent to TrustBeat.

\n
    \n
  • Submission without the file. The subscriber runs TrustBeat's extractor (trustbeat-signature), a\nprogram on its own computer. The extractor reads a signed file, takes out each signature, computes the\ndigests of the signed data and of the whole file, checks that the signatures cover the data they claim\nto cover, and sends only that (the submission) to TrustBeat. TS 119 511 allows a detached signature\nwith only a hash of the signed data (OVR-9.3-05). The extractor is open source (MIT) and published, with\nits releases, at https://github.com/TrustBeat/trustbeat-signature; how to obtain and check it is in\nthe practice statement.
    • \n
  • Checks by TrustBeat. TrustBeat re-derives, from inside each signature, the digests the submission\ndeclares and rejects the submission if they differ. It validates each signature with EU DSS under the\nsignature validation policy, collects the certificates, OCSP responses and CRLs needed to validate it\n(OVR-9.3-01) and records the result as found on the day. A signature is preserved whatever the result:\nthe record says what the validation found, it does not decide whether a signature is acceptable.
    • \n
  • Preservation Evidence Object (PEO). All of it — the signatures byte for byte, the declared digests,\nthe validation data, the validation result, and references to the EU Trusted Lists in force — goes into\none canonical JSON document per submission, the PEO. TrustBeat stores the PEO.
    • \n
  • Evidence. The PEO's SHA-256 digest is time-stamped in the same way as a document anchor: combined\nwith other digests of the same 10-minute cycle in an RFC 4998 hash tree whose root is time-stamped by an\nEU qualified time-stamping authority. The resulting RFC 4998 evidence record proves that the PEO, and so\neach signature and its validation data, existed at that time and has not changed since.
    • \n
  • What is proven about the signed data. The evidence covers the signatures and the digests of the\nsigned data, not the data. It extends to the signed data only while the hash algorithms of the\nsignatures and of the declared digests stay collision-resistant, and only for the data the subscriber\nkept. The digests are computed by the extractor on the subscriber's side: TrustBeat cannot check that\nthey were computed from the real file (OVR-9.3-07, 6.2-08).
    • \n
  • Preservation period. 30 years from submission, on every plan. A subscriber agreement may set a\ndifferent period. Time-stamp renewal keeps the evidence verifiable for the whole period.
    • \n
  • Renewal (augmentation). As for document anchors: RFC 4998 time-stamp renewal (§5.2) before the last\ntime-stamp stops being verifiable. Because TrustBeat holds the PEO, it can also renew the hash tree\n(§5.3) by re-hashing the PEO with a stronger algorithm; the PEO already carries SHA-512 and SHA3-512\ndigests of the signed file for that case. When and how: evidence policy §4 and §8 (OVR-6.5-07).
    • \n
  • Missing validation data (OVR-6.2-06). If some validation data cannot be obtained (for example an\nOCSP responder does not answer), the signatures are preserved anyway and the PEO lists what is missing.\nThe submission is not refused.
    • \n
  • End of the preservation period. As for document anchors: TrustBeat notifies the subscriber and\nmakes the record's package available; 30 days later it deletes the PEO, the record's metadata and\nits link to the subscriber, and stops serving its evidence. Renewal stops at the end of the period\n(OVR-6.1-09). Before that, the subscriber can delete a record at any time (below).
    • \n
\n

Accepted signatures (OVR-6.4-04 b, OVR-9.3-06, OVR-9.3-08)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Container (file the subscriber holds)Signatures taken outSigned data bound by
PAdES (PDF)Each signature dictionary's /Contents (detached CAdES), across incremental updates; document time-stampsdigest of the /ByteRange; whether the signature covers the whole file
CAdES detached (.p7s + data)The CMS SignedDatamessageDigest of each signer
CAdES enveloping (.p7m)A copy of the CMS with the encapsulated content removed (marked content-detached)messageDigest of each signer
XAdES detached, enveloped, envelopingds:Signature (with inherited namespace declarations added; for enveloping, without the signed ds:Object, marked as such)ds:Reference digests; canonical SignedInfo digest
ASiC-E, ASiC-S with XAdES or CAdESEvery signature file, every ASiCManifest, container time-stampsreferences / manifest entries; digest of every data file
\n

Not accepted in this profile (the extractor refuses the file and says why): JAdES; files without a\nsignature; signed data that no longer gives the digest inside its signature; detached signatures or\ncontainers whose signed data is missing; XML with a DOCTYPE, XML transforms other than enveloped-signature,\nC14N 1.0 / 1.1 / exclusive, base64 and the XPath patterns that remove signatures; encrypted PDFs; signers\nwithout signed attributes. A PDF changed after its last signature is accepted: the record states which\nsignatures do not cover the whole file. One submission per signed file, with at most 100 signatures,\n100 time-stamps and 10 000 data objects.

\n

Hash functions of the declared digests (OVR-9.3-06). Every file and data object: SHA-256, SHA-512\nand SHA3-512, all three, hexadecimal. The digests inside a signature use whatever algorithm the signature\nuses, as long as the signature validation policy can process it. TrustBeat checks every digest's identifier\nand length (OVR-9.3-08) and treats the declared digests as general data (OVR-9.3-07).

\n

A file signed again later is a different file. A record covers the signatures the file had when it was\nsubmitted. If the file is signed again afterwards, preserve it again after its last signature.

\n

Supported operations (OVR-6.4-04 b, PRP-8.1)

\n

TrustBeat uses its own REST API, documented at https://api.trustbeat.eu/docs, rather than the\nTS 119 512 protocol (PRP-8.1-02 is a recommendation).

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
OperationTS 119 512 equivalentEndpointInputOutput
PreservePreservePOPOST /v1/signature-preservationSubmission JSON (format trustbeat-signature submission v1), produced by the extractorPreservation object identifier (id), status
Retrieve statusRetrieveInfo (per object)GET /v1/signature-preservation/{id}IdentifierStatus (pending → anchored → preserved), signatures with the validation results, profile, end of the preservation period, evidence record link
ListSearchGET /v1/signature-preservation—The subscriber's records
Retrieve evidenceRetrievePOGET /v1/public/proof/{id}/evidence-record.ersIdentifierRFC 4998 evidence record over the PEO (DER)
Retrieve preserved object and evidenceRetrievePOGET /v1/signature-preservation/{id}/packageIdentifierExport-import package (below)
Retrieve profilesRetrieveInfoGET /v1/preservation/profiles—This profile and every other one (JSON)
Validate evidenceValidateEvidencePOST /v1/signature-preservation/{id}/verifyIdentifier + a submission of the file presented nowVerification report (JSON, or PDF with ?format=pdf)
DeleteDeletePODELETE /v1/signature-preservation/{id}?confirm={id}Identifier, repeatedDeletion confirmation. Removes the PEO, the signatures and the metadata, and stops serving the evidence; the PEO's digest stays in the shared hash tree. Final. Logged; the account is emailed (practice statement §6).
\n

Export-import package (§7.16). GET /v1/signature-preservation/{id}/package, one per record: a ZIP with\nthe PEO exactly as stored, every preserved signature, ASiCManifest and time-stamp in its native format,\nthe certificates, OCSP responses and CRLs, the RFC 4998 evidence record once ready, the signed EU Trusted\nLists the PEO refers to, a manifest.json with the SHA-256 of every file, and a README.txt with the\nverification steps. Format and verification: practice statement §5.

\n

Verification without TrustBeat. The package and the original file can be verified offline with the\nextractor (trustbeat-signature verify <file> --package <zip>) or with standard tools, step by step\n(practice statement §2.3).

\n"}