From 9363a2ca7e9e624ea8827edba639f0deaff9180a Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 3 Jun 2024 15:36:55 +0200 Subject: [PATCH 1/3] [Credential Lifecycle] - Revocation with retroactive flag This commit aims to resolve the issue https://github.com/italia/eudi-wallet-it-docs/issues/264 --- docs/en/revocation-lists.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 908e41111..69257a804 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -100,6 +100,9 @@ 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 flag 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. If the "retroactive flag" is activated, the credential MUST be invalid also for the period prior to the revocation date. If the "retroactive flag" is not activated, 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: From c5dd8dcae76e17201bd6393c2a255f1324601c56 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 28 Jun 2024 11:57:45 +0200 Subject: [PATCH 2/3] Updated according to the latest "draft-demarco-oauth-status-assertions" specifications. --- docs/en/revocation-lists.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 69257a804..f15437839 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -102,7 +102,11 @@ Credential Revocation Flows can start under different scenarios, such as: 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 flag 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. If the "retroactive flag" is activated, the credential MUST be invalid also for the period prior to the revocation date. If the "retroactive flag" is not activated, 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. +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: From 14e7525daaecf323fd139bb494ac86fcc4d30e91 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 28 Jun 2024 12:35:10 +0200 Subject: [PATCH 3/3] blank space removed --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index f15437839..8f0da754f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -104,7 +104,7 @@ The Credential in some cases MUST be considered valid (thus is still accurate, u 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 ``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.