How to migrate servers

[brianorwhatever]

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 the id 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?

[swcurran]

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 did:tdw identifier helps, I think. I propose that a change of location of the DID is (by definition) in the hands of the DID Controller (since it is…). We recommend (require?) that a change of id include the placement of the old id into the alsoKnownAs. Technically, this creates a new DID (but same SCID) but allows/requires the new DID to retain the history (since the use of the same SCID requires it). Web redirection techniques can be used to enable retrieving the history by resolving its old URL. We discourage DID controllers from forking a DID, but I don’t see there is any need to prevent it, since it is a new DID, and the DID Controller has signed the forks.

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.

[andrewwhitehead]

I think you might be right that the id property is redundant. We can narrow down the expected behaviour where the host/location of the DID document might change. Say we have it move from ID-1 = did:tdw:host1:scid to ID-2 = did:tdw:host2:path:scid:

• After moving, the original DID history URL must still be accessible for the DID to be resolvable. It could redirect to the new URL, or it could potentially have a moved parameter added to the document containing the new URL. Requests to resolve ID-2 should probably not fail just because the first transaction contains a document with @id = ID-1.
• I'm not certain whether it's acceptable behaviour for the resolver to return a document with @id = ID-2 for a request to resolve ID-1. If not, then in this case I suggest the didDocument should be null, and the didResolutionMetadata should have something like a moved property containing the new DID, leaving it up to the client to perform a new request. The resolver could technically return a redirect status code and Location header as well, although I'm not sure if that's sanctioned.
• I do believe that the resolver should fail resolution with an error if it gets to the end of the log (or possibly to the requested versionId/versionTime) and the @id is not consistent with the host and path currently being requested, with allowances for redirects.

[swcurran]

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 alsoKnownAs, and the current ID. I think that would be better than failing to resolve. I think this is valid since the verification of the DID is by verifying the log and as long as it is valid, returning a derived DIDDoc is permitted.

We talked a lot in the did:webs group about equivalentDID, which is part of the DID spec. From @peacekeeper ’s explanation, an equivalentDID is one that is the same type and same content. So perhaps we only allow a change of location via a DIDDoc that has a new id and has the old id (previous DIDDoc) in the equivalentDID location.

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.

[brianorwhatever]

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:

1. did:td - The DID log format and processing we have almost nailed down. This method wouldn't be resolvable unless you get the did.log file
2. did:tdw - Using did:td on the web. This method would define how to download the log when using a web server

We could then show how migrations from did:td -> did:tdw would work (change the id property) which would show confidence in the portability of a log.

I think this separation of concerns might be a good idea. Thoughts?

[swcurran]

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.

[brianorwhatever]

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 🏆

[swcurran]

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.

[andrewwhitehead]

I do like the idea that we could migrate the log to another DID method by just changing the method param and updating the document. To me it's more of a "DID document management process" than a DID method on its own, as it would still require a concrete DID method to define the resolution of the history state and the format of the identifier. If say you're resolving a did:tdw that started on bitcoin, it should not need to know all the processing and validation rules defined by the bitcoin method as long as the final document state is consistent with did:tdw and it can find the authentication keys along the way.

The moved parameter would also come in handy here as you can't always rely on an HTTP redirect.

[swcurran]

If we can just specify the case of changing from one did:tdw to another because of a forced move, I’d be happy...

[brianorwhatever]

Ok, will update my implementation to include the domain in the initial creation.

[brianorwhatever]

In this commit I am creating a DID with domain example.com and then subsequently changing the domain to migrated.example.com