DTBS

DTBS is the data a signer intends to sign; DTBS/R is its usually hash-based representation processed by an HSM or QSCD when creating an e-signature.

DTBS (Data To Be Signed) is the content a signer intends to sign, such as a document or a set of data fields, while DTBS/R (Data To Be Signed Representation) is the technical representation of it that the signing device actually processes. Both terms come from CEN/CWA standards and Common Criteria Protection Profiles for signature creation devices; eIDAS itself does not use the term DTBS/R, though the ETSI and CEN standards it references do. Signature algorithms are designed to operate on a fixed-length digest rather than an arbitrarily large file, so a hashing step typically produces the DTBS/R; depending on the standard - such as CEN EN 419241 and EN 419211 - and the signature format, the DTBS/R may be a plain hash, a padded or DigestInfo-encoded digest, or in some cases the DTBS itself.

In AdES signature formats (PAdES, XAdES, CAdES, JAdES), the value that is actually hashed and signed is often not the document hash directly but the hash of a signed-attributes or SignedInfo structure that in turn references the document hash, adding a layer between DTBS and DTBS/R that is easy to overlook. In remote signing via a CSC-style API, the signing application computes the DTBS/R and sends it to the HSM or QSCD, which processes it under the signer's sole control using the signature-creation-data; the SAD (Signature Activation Data) generated through the signature activation protocol is designed to bind the signer's authorisation to that specific DTBS/R, which is the core mechanism enforcing sole control in a remote setup.

The distinction matters for signature-validation: a valid signature proves the DTBS/R was signed with a given key, and matching that representation back to the original DTBS confirms document-integrity. eIDAS Annex II requires that a QSCD does not alter the data to be signed and does not prevent that data from being presented to the signatory prior to signing (the WYSIWYS principle) - a safeguard rather than a positive presentation requirement, but one that anchors the link between DTBS and DTBS/R in practice: what the signer reviews should correspond to what is ultimately hashed and signed. The mapping between DTBS and DTBS/R must be unambiguous - if the hashing method is weak or the mapping is unclear, the evidential value of the signature can be undermined even though the cryptography itself is sound.