Should this method have an easy solution to "Right to be forgotten"?

[brianorwhatever]

Currently the deactivate method still returns a DID and the log still exists. Should we make this more robust and delete the log or something along those lines?

[Reccetech]

In the conversation @swcurran mentioned that a 3rd party operator handling a "right to be forgotten" request could just delete the relevant DID log and then anyone trying to resolve the DID would get a 404. I think this is a satisfactory solution. Maybe a description of this flow can be added to the spec under "Security and Privacy Considerations"

[ankurdotb]

There are valid reasons why someone might want to resolve (and receive) a DID Document for a deactivated DID. See discussion on W3C: w3c/did-resolution#5

Example I used is if I had a degree certificate issued as a credential from a university 10 years ago, but that DID has been deactivated (for whatever operational reason). As a holder of this degree, would still want someone to be able to validate that it was valid at that time

[swcurran]

@ankurdotb — I think you are describing a different concern from why this issue was raised. In this issue, the concern is the desire to delete a DID, because I’m the DID Controller and I want it removed. Perhaps it is on a service like Bluesky, represents me as a DID Controller, and I want it removed.

You are looking at the other side of long lasting DID resolution — being able to resolve a DID after it “disappears” because the DID Controller has disappeared or removed it. Obviously, a DID Controller can choose to remove a DID, but that leaves those holding verifiable credentials (signatures) unable to have them verified. For that, the best answer is a Watcher that (independent of the DID Controller) monitors and maintains DIDs so that they can be resolved and used to verify signatures. Given a did:webvh DID Log from any source, and a reference in a verifiable credential to that DID, the DID Log can be verified, and the relevant key in the DIDDoc used to verify the verifiable credential.

[ankurdotb]

That makes sense, thanks for the clarification!

[swcurran]

Do we need to add anything to the spec on this? It's not a technical change, but perhaps a clarification.

[ankurdotb]

I think so, yes. The current specification only has text about deactivation but not deletion (unless I've missed it)?