From b1c52f4ca600fbff83b720110b09c16ebebac4db Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 7 Jan 2024 16:10:52 -0500 Subject: [PATCH 1/2] Add Security Considerations section on deletion. --- index.html | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/index.html b/index.html index 6c1ddaf..e5a2781 100644 --- a/index.html +++ b/index.html @@ -1017,6 +1017,51 @@

Privacy Considerations

Security Considerations

+ +
+

Deletion

+ +

+The APIs provided by this specification enable the deletion of +verifiable credentials and verifiable presentations from +storage services. The result of these deletions +and the side-effects caused by them are out of scope for this specification. +However, implementers are advised to understand the various ways deletion can be +implemented. There are at least two types of deletion that are contemplated by +this specification. +

+ +

+Partial deletion marks a record for deletion but continues to store +some or all of the original information. This mode of operation can be useful if +there are requirements to be able to audit all credentials or presentations over +a particular time period or if recovering the original credential might be a +useful feature to provide an entity. +

+

+Complete deletion purges all information related to a given +verifiable credential or verifiable presentation in a way that +is unrecoverable. This mode of operation can be useful when removing information +that is outdated and beyond the needs of an audit or when responding to any +sort of "right +to be forgotten" request. +

+

+When deleting a verifiable credential, what to do with the status +information needs to be considered. Some use cases might call for a deletion +of a particular verifiable credential to also set the revocation +and suspension bits of the verifiable credential such that any sort of +status check for the deleted credential fails and usage of the credential is +halted. +

+

+Given the scenarios above, it is advisable that implementers allow the +moderation of what happens after a delete to be programmable such that +system flexibility is achieved to address any verifiable credential use +case. +

+
+
From 223646828d5e73728e7dda910bf526803b1a3043 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Tue, 23 Jan 2024 14:20:02 -0500 Subject: [PATCH 2/2] Fix grammar in Security Considerations section on Deletion. Co-authored-by: Ted Thibodeau Jr --- index.html | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index e5a2781..99390a0 100644 --- a/index.html +++ b/index.html @@ -1025,7 +1025,7 @@

Deletion

The APIs provided by this specification enable the deletion of verifiable credentials and verifiable presentations from storage services. The result of these deletions -and the side-effects caused by them are out of scope for this specification. +and the side-effects they might cause are out of scope for this specification. However, implementers are advised to understand the various ways deletion can be implemented. There are at least two types of deletion that are contemplated by this specification. @@ -1034,31 +1034,30 @@

Deletion

Partial deletion marks a record for deletion but continues to store some or all of the original information. This mode of operation can be useful if -there are requirements to be able to audit all credentials or presentations over -a particular time period or if recovering the original credential might be a -useful feature to provide an entity. +there are audit requirements for all credentials and/or presentations over +a particular time period, or if recovering an original credential might be a +useful feature to provide.

Complete deletion purges all information related to a given verifiable credential or verifiable presentation in a way that is unrecoverable. This mode of operation can be useful when removing information -that is outdated and beyond the needs of an audit or when responding to any +that is outdated and beyond the needs of any audit or when responding to any sort of "right to be forgotten" request.

-When deleting a verifiable credential, what to do with the status -information needs to be considered. Some use cases might call for a deletion +When deleting a verifiable credential, handling of its status +information needs to be considered. Some use cases might call for deletion of a particular verifiable credential to also set the revocation -and suspension bits of the verifiable credential such that any sort of -status check for the deleted credential fails and usage of the credential is +and suspension bits of that verifiable credential, such that any sort of +status check for the deleted credential fails and use of the credential is halted.

-Given the scenarios above, it is advisable that implementers allow the -moderation of what happens after a delete to be programmable such that -system flexibility is achieved to address any verifiable credential use -case. +Given the scenarios above, implementers are advised to allow the system actions +that occur after a delete to be configurable, such that system flexibility is +sufficient to address any verifiable credential use case.