What happens when you delete a revocable credential?

[OR13]

Specifically, what happens to the status bits?

https://github.com/w3c-ccg/vc-api/pull/271/files#r837514390

[msporny]

The group discussed this on the 2022-05-17 telecon. @jandrieu noted that the question is difficult to explore without knowing which system component we are talking about. If we focus on Issuer Service, it was noted that Issuer Service might not need to store VCs in this way. If it's the Issuer App, there might be a need to store and delete the credential.

The group was not able to have a productive discussion around the question because it was not clear which component of the ecosystem was doing the deletion (or having the deletion affect it). It was also not clear what the "DELETE" HTTP verb meant for different aspects of the system. DELETE on a credential in a Holder wallet is semantically different than DELETE on a credential in an Issuer App (and or Service).

The group needs the caller, the component, and the semantics around the DELETE operation identified in order to make progress on this issue.

[msporny]

The group discussed this on the 2023-04-11 telecon and noted that we have now split system components and have Issuer Coordinators and Issuer Services. The question was raised about which service is doing the delete? The Issuer Service or the Holder Service?

@jandrieu noted that there is an easy answer -- DELETE and revoke have different semantics. Delete is about removing something that's stored, issuer can delete w/o revoking. We don't know that semantics are always aligned, so we need to allow them to be separate. @dlongley recommends something similar, we might not have to force interop here or be prescriptive. We can allow implementations to just perform a delete, or throw an error if a delete is performed before something is revoked. Unsure how much we have to try to get interop here, not clear how people might want these systems to perform. @jandrieu noted that we don't have a requirement for anyone to store issued VCs. @dlongley noted that's correct, but, if you have a status list, there is a presumption that you're keeping some information around VCs to allow status to be changed. There are VCs that don't have status, where you can delete without changing status (revoke). If you are not tracking status, delete and revoke are no ops. When you delete a credential, are you deleting ability to modify status? What is the scope of delete? issued VC or removing metadata around VC? @dlongley thought it would be the latter, we would have no API to do that... there might be some linkage between status and storage. Alan Karp noted that if you revoke, you have to have a place where you store whether or not the thing was revoked. @jandrieu noted that one of the discussions is "What are the semantics when you delete a revoked credential?" -- there are different semantics for delete, revoke, purge, and that might be the space we need to understand better before we get to implementation advice. @dlongley noted that if we introduce "purge", that creates implications on how you impelment the system... if you don't have that, it provides another implication -- touchy, main reason being we don't want to make a normative decision where we want to see it play out in the market, if there is a way that comes out as the "best" way for it to work... it's too early to do that now. @PatStLouis noted that drafting a matrix might be helpful (if revoked, delete, consider X... if not revoked, delete, consider Y, etc.)

The next step here is to raise a PR that:

• Iterates through a matrix of all possibilities of DELETE + status list statuses
• Provide thoughts on each combination, but make it clear that it's too early for normative guidance.
• Suggest to implementers that DELETE should be "soft" delete, which might include garbage collection that implementers can do (or non-deletable substrate) -- if DELETE had been issued, item could be garbage collected OR you could decide to never delete (audit system keeps permanent record)
• Talk about how expiration interplays w/ DELETE and revoke
• Note reasons why you might want to keep around an expired credential (you might not ever want to remove it) -- use in a reapplication process, present an expired credential, etc.

[msporny]

PR #360 has been raised to address this issue. This issue will be closed once PR #360 has been merged.

[msporny]

PR #360 has been merged, closing.