|
There are two keys that can be used for DID updates. One is the signing key that the publishing server may also control, one one is the recovery key. If a content server goes rogue, the recovery key can be used within 72 hours to retroactive undo changes made to the DID (if the server did that). If the server just maliciously messed with your data repository, you just use the recovery key. If the malicious content server did not try to rotate the recovery key, you can just use it to reset the signing key, regardless of if the content server rotated it. If it did malicious try to rotate the recovery key, as long as you notice within 72 hours, you can fork a new DID history from some state that was current within the last 72 hours that has your old recovery key. Either way, you use the recovery key to rotate the signing key, to something you control. Now, you can repoint your DID to a new content server, upload your unadulterated post history to it. Also, the core of the protocol does not strictly require that the content server have your publishing keys. In theory a client can create new posts, sign them and upload them. This will mean that certain API methods that exist that do things like add a new post won't work, which is theoretically fine if you only ever want to post from fully trusted clients that could be given access to your signing key, create a new commit, and upload it. Also it is not yet clear if all servers will allow such usage. In theory a content server could refuse to host the data repositories for users if it lacks the signing key for the user. Footnote: These content servers are formally called Personal Data Servers. I used content servers throughout this post to be clear that I am not talking about plc.directory or other such ancillary servers. |