diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst
index 908e41111..8f0da754f 100644
--- a/docs/en/revocation-lists.rst
+++ b/docs/en/revocation-lists.rst
@@ -100,6 +100,13 @@ Credential Revocation Flows can start under different scenarios, such as:
     - The Authentic Sources that for any administrative reasons update one or more attributes of a User, shall inform the Issuer of related Credentials. 
     - The Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, death of the User, etc.), can decide to revoke the Credentials.
 
+The Credential in some cases MUST be considered valid (thus is still accurate, useful and valid) for the period before the revocation: a driving license, revoked due expiration or other reasons, is still valid for the period before the revocation.
+ 
+Revocation MUST therefore include a parameter indicating whether it is retroactive or not. It SHOULD not invalidate further use of the credential, as it MAY be used to attest activity outside the revocation interval. This parameter name is **credential_status_validity** and contains two additional parameters to handle the Credential retroactivity: **suspended** and **revoked**.
+
+If ``revoked`` parameter is set to ``true``, the credential MUST be invalid also for the period prior to the revocation date. 
+
+If ``suspended`` parameter is set to ``true``, the credential MUST be considered valid up to revocation date and could be used to demonstrate that, before revocation, the holder was entitled to perform related activities.
 
 The revocation scenarios involve two main flows: