Markus Sabadello

Related issue is https://github.com/w3c/did-spec-registries/issues/174, which also discusses tracking contact information for DID methods and other additions to the registry.

+1 I also agree it makes sense to distinguish between a DID that has been revoked, and one that doesn't exist. (At least if a method supports this, I could...

Good points, I agree with both. We can have a warning in the spec about security implications of "revoked" vs "deleted", and we could add versioning information to the DID...

Good points, versioning (and the ability to resolve earlier versions of a DID Document) is definitely one of the features that needs to be addressed in the DID Resolution spec....

@ankurdotb Thanks for sharing detailed thoughts on this! Personally I don't have a strong opinion here and could live with either approach. I think DID Core supports your arguments, since...

> The change I'd make is to set `didResolutionMetadata` to return a different value instead. > `didResolutionMetadata`: "didDeactivated" I don't really understand what you mean here. According to DID Core,...

Also pinging @fabianekc since he also had some thoughts about DID rotation, forwarding, redirecting.

> * The only fallback available here would be to return a 404 not found error (same as if the DID queried didn't exist). This is obviously less than ideal,...

After today's discussion, I think next steps here are: - For now, no changes are necessary to how deactivated DIDs are currently treated in the DID URL Dereferencing algorithm and...

As discussed, this topic has been moved to DID Extensions: https://github.com/w3c/did-extensions/issues/622