-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to migrate servers #19
Comments
This is something that KERI attempts to address as well — “duplicity” in their world. And this is where they get into the complicated world of “witnesses” and “watchers” and the like. The controller of an identifier forks the identifier and tells one person the DID of one fork, and the other the DID of the other fork. In KERI, there is only the “AID” (what we call the SCID) so the “duplicity” has to be identified in some other way. The addition of the discovery information as part of a This is where pre-rotation would be very helpful, as an additional layer of defense from the DID Controller with a compromised key. A properly managed pre-rotation key would make a malicious fork much more difficult. |
I think you might be right that the
|
I think that if the resolver is called with a DID that it can actually resolve — via a redirection — then I would argue it would be reasonable to fully verify the history, and then in returning the requested DIDDoc, swapping the DID passed in to the resolved (now in We talked a lot in the Of course, if you longer control the web domain such that you can’t put in a redirect, the resolution would fail. We need to balance what we put into the normative part of the spec. about this (and in the verification code), and what we put in the implementation guide about edge cases. I can see we need something in the normative text about relocating a DID, but we should be careful not to overdo it — leaving implementations to minimize the enforcement. |
I wonder if what we should be doing is defining 2 DID methods (I know, I know there is already too many DID methods but here me out..) We could be defining:
We could then show how migrations from I think this separation of concerns might be a good idea. Thoughts? |
I don’t see the benefit of going in with that, vs. if others like the log format, picking it up. My concern is trying to make the log format general purpose enough to support all DID Methods — as we’ve talked about before. I also don’t think that the log format itself, is a “DID Method”. It might be a useful thing for other DID Methods to use, but I think it is too big a battle to try to convince others to use that. Let them come to it if it is valuable in their context. That said, I don’t think that even with that, it helps with the issue — “how to migrate servers”. I think that is purely a “did:tdw” concern. |
It is already general purpose enough 😃. I didn't add domain stuff into my implementation until my latest commit. And even now I'm not doing it as discussed.. I'm adding the domain on the first update (see here). It most certainly could be a DID method since that's what my implementation has been doing for the majority of it's life 😅. Albeit not a very useful without a resolvable method on top.. If we don't separate it out I would at least like it to be clear in the spec where the lines are. My concern is if we write this thing to be too "web" oriented people won't even consider the possibility they could use the same log format. I don't want to battle others to convince them to use it I just want to make it clear they can easily and hopefully they agree and use it. I guess this is more related to "how to migrate to another method that uses the same log format". True portability.. The holy grail 🏆 |
I think would I would like to do is define the spec and have a section on the parts of the spec that could span be valuable in the DID Spec or for other DID methods. And definitely in presenting this DID Method, we would talk about that. |
I do like the idea that we could migrate the log to another DID method by just changing the The |
If we can just specify the case of changing from one did:tdw to another because of a forced move, I’d be happy... |
Ok, will update my implementation to include the domain in the initial creation. |
In this commit I am creating a DID with domain |
Resolved in the specification by enabling control of whether or not a did:tdw supports portability and how to rename a DID while retaining its SCID and history if it does support portability. |
Ideally there is a method to migrate servers so you are not tied to a specific server and can easily migrate. I think this can be accomplished by updating the
id
in the document. I think this makes theid
property redundant here @andrewwhitehead. But I'm just now as I'm typing this realize this opens up forks..I drew up a picture to explain what I'm talking about
At the end of the day I think we need a way to freely migrate. How do we accomplish this?
The text was updated successfully, but these errors were encountered: