[Credential Lifecycle] - Revocation with retroactive flag #302
Conversation
This commit aims to resolve the issue italia#264
| @@ -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. | |||
There was a problem hiding this comment.
| 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. | |
| There are cases where a Credential MAY be considered valid (thus is still accurate, useful and valid) for a period after the revocation: a driving license, revoked due expiration or other reasons, MAY be still valid for the period after the revocation. |
is this what you want to say?
could you please bring also legal evidences as example according to the italian regulation?
There was a problem hiding this comment.
Not really, considering the example of Residence Certificate: I may be resident in Rome up to 31st of December 2023. I change my residency to Milan from 1st of January 2024, thus the previous residency certificate gets revoked.
The residency certificate revoked (Rome's residency) is still valid for any activity/action related to year 2023 and before (e.g. I need to pay taxes in Rome city for 2023, and these taxes are paid in 2024).
There was a problem hiding this comment.
the scope of this project is the definition of the technical rules. Legal and administrative aspects specifically related to the scopes of the credentials, according to their type or use cases, must be taken out of this specification.
There was a problem hiding this comment.
As a general comment, the verifier policy always determines "validity", issuer's provide guidance and integrity protection, the "validity" is always in the eye of the verifier.
You might consider language like:
A verifier MAY accept credentials presented outside of their validity period, or with revoked or suspended status.
Verifier policies are out of scope for this document.
docs/en/revocation-lists.rst
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
Where this "flag" was discussed?
There was a problem hiding this comment.
When there are 2 only possible options, you can differentiate them with a flag instead of having different parameters as the differentiating factor doesn't change the overall specifications. This is an approach, if you prefer different approach let us know
There was a problem hiding this comment.
I would be cautious not to expose/mix operational guidance to issuers and verifiers, with protocol guidance to implementers.
For example:
It is recommended that Issuers maintain a log including the time and optionally reason for revocation or suspensions.
Retention policies for such logs are out of scope for this specification, and may be constrained by regional requirements, etc...
|
According to the conversation made during the last call, we require that the legal team must bring the evidences about the legal requirements pertaining the credential revocation and validity on the edge cases. once we have the legal requirements we'll bring requirements and technical solution here. |
This commit aims to resolve the issue #264