Fix decorators

Signed-off-by: Riccardo Iaconelli <[email protected]>

docs/en/backup-restore.rst

@@ -15,7 +15,7 @@ This document proposes a technical solution for the backup and restoration of di
 What data can be backed up
 ------------------
 
-The ARF differentiates between Type 1 and Type 2 configurations. Type 1 is designed for PID and (Q)EAA with LoA High, while Type 2 may be used for QEAAs and EAAs. The primary difference between the two configurations is that Type 1 must use the holder key binding. A proof of possession - such as the one described in RFC7800[1] - is included in the PID; it consists of the User’s device public key signed by the PID Provider. The corresponding User’s device private key should be securely stored in the Secure Element[2] of the User’s device (or a remote HSM when the SE is not available). By signing typically random information during the presentation phase to a Relying Party, the device can thus prove the legitimate possession of the PID.
+The ARF differentiates between Type 1 and Type 2 configurations. Type 1 is designed for PID and (Q)EAA with LoA High, while Type 2 may be used for QEAAs and EAAs. The primary difference between the two configurations is that Type 1 must use the holder key binding. A proof of possession - such as the one described in RFC7800[1] - is included in the PID; it consists of the User's device public key signed by the PID Provider. The corresponding User's device private key should be securely stored in the Secure Element[2] of the User's device (or a remote HSM when the SE is not available). By signing typically random information during the presentation phase to a Relying Party, the device can thus prove the legitimate possession of the PID.
 
 Type 2 (Q)EAA, on the other hand, may include a public key for proof of possession, and, if it does, the corresponding private key may be exported if it is not stored on the Secure Element. A credential should either be holder-bound with a non-exportable key or not holder-bound at all.
 
@@ -31,7 +31,7 @@ Backup methods
 
 Given the sensitive nature of the data, backups must be encrypted. When encryption is applied, it should be done with a User-provided passphrase or any other means that the User has sole control over. 
 
-The backup should be stored as a serialized file (hereafter referred to as the “Backup File”) in an open format. The Backup File should include a timestamp in its name to facilitate chronological sorting, as illustrated in the non-normative example below: 
+The backup should be stored as a serialized file (hereafter referred to as the "Backup File") in an open format. The Backup File should include a timestamp in its name to facilitate chronological sorting, as illustrated in the non-normative example below: 
 
 eudiwallet-backup-2023-02-01T08:03:11Z.eudiwb
 
@@ -99,12 +99,12 @@ The backup file consists of a structured document. The schema should contain at
    * credential type;
    * credential issuer.
 
-The content should be encrypted and protected by a passphrase or other mechanisms. Below is a non-normative example of the content of a Backup payload, where the first entry must be the reference to the User’s PID (its type and its issuer). 
+The content should be encrypted and protected by a passphrase or other mechanisms. Below is a non-normative example of the content of a Backup payload, where the first entry must be the reference to the User's PID (its type and its issuer). 
 
 Recover
 ------------------
 
-Recovering an EUDI Wallet from a Backup File may follow different flows depending on the backup method and configuration types. Each recovery always begins with the issuance of a new PID. Once the new Wallet Instance is in the valid state, the User is prompted for a recovery from a backup. The User chooses a backup recovery method (USB device, cloud[5], …), the Wallet Instance then asks the User for the passphrase to unlock the Backup File, and analyze the content inside it.
+Recovering an EUDI Wallet from a Backup File may follow different flows depending on the backup method and configuration types. Each recovery always begins with the issuance of a new PID. Once the new Wallet Instance is in the valid state, the User is prompted for a recovery from a backup. The User chooses a backup recovery method (USB device, cloud[5], ...), the Wallet Instance then asks the User for the passphrase to unlock the Backup File, and analyze the content inside it.
 
 When a Type 2 credential has a Cryptographic Holder Key Binding and the private key is backed up, the credential can simply be copied over on the new device together with its key, and continues to be valid and possession-provable.