anchor.diff:  
   Although it is possible to only run the validation process for basic signature, in our case the process that was run was the "validation process for Signatures providing Long Term Availability and Integrity of Validation Material" which required to run the other two validation processes.
   
  -Therefore, because that validation process returned PASSED, the overall validation result is TOTAL_PASSED.
  +Therefore, because that validation process returned `PASSED`, the overall validation result is TOTAL_PASSED.
   
   Finally, the report contains information on the determination of the qualification of the signature.
   
   image::DetailedReport-Illustration-Qualification.png[width="100%", height="100%", align="center"]
   
  -This determination is not specified in ETSI EN 319 102-1, but rather in ETSI TS 119 172-4 (<<R10>>).
  +This determination is not specified in ETSI EN 319 102-1 (<<R09>>), but rather in ETSI TS 119 172-4 (<<R10>>).
   
   Essentially, a signature can be determined as qualified if:
   
  -. The result of running the "validation process for Signatures providing Long Term Availability and Integrity of Validation Material" defined in ETSI EN 319 102-1 is TOTAL_PASSED
  +. The result of running the "validation process for Signatures providing Long Term Availability and Integrity of Validation Material" defined in ETSI EN 319 102-1 is `TOTAL_PASSED`;
   . The signing certificate is determined as qualified at best-signature-time and at issuance time (the time when the certificate was issued i.e. the value of the "notBefore" field);
   . The private key corresponding to the signing certificate is determined as being held in a qualified signature creation device (QSCD).
   
  
positive.code: 
  
  [[Topology]]
  === Examples of SCA and SCDev Topology and Workflows.
  
  ==== Hash computation
  In order to avoid transfer of original or sensitive information, and also to reduce the amount of data by online protocols, a hash of a document or data to be signed can be computed.
  
negative.code: 
  According to ETSI EN 319 102-1 (cf. <<R09>>), the signature validation process can be separated to different levels:
  
  * *Validation process for basic signatures* - validates the signature at the validation (current) time;
  * *Validation process for Signatures with Time and Signatures with Long-Term Validation Material* - verifies the signature against its _best-signature-time_ (i.e. against the signature time-stamp's production time);
  * *Validation process for Signatures providing Long Term Availability and Integrity of Validation Material* - verifies the signature with all available Long-Term Availability material (i.e. including the validation of archive time-stamps).
  
  DSS allows the user to choose the validation level when performing a signature validation, i.e. to specify the validation process to be used for validation (cf. <<R09>>). By default, the highest level (with LTA enabled) is used.
  
  