Portable DID resolution

[kdenhartog]

Has there been any thinking about how we would resolve a DID that has been re-anchored? Particularly where I think this is relevant is if I want to anchor a peer DID to a ledger later, or if a ledger dies and I want to port my data from one ledger to another. I know people have mentioned use cases of this in the past before, but I wasn't sure how it would be handled. My current mental model is that the DID method is how the resolver knows which ledger to check which seems incompatible with this use case.

[talltree]

@kdenhartog DIDs are not portable in the sense that the DID controller can move a DID from one DID registry to another DID registry (i.e., from one DID method to another DID method). The "portability" is the DID controller's ability to use the DID wherever the DID controller wants, not the ability to port the DID to another DID registry.

(This, BTW, is one reason I don't like the term "DID registry"—because it suggests portability of a DID from one registry to another like phone number portability in the U.S. for example. I prefer the term "DID network".)

[kdenhartog]

Is this because we don't want this to be possible, or that we don't believe it to be technically possible? It's worth point out that right now the Peer DID method spec points out this capability. Is it acceptable for a DID to redirect to a different DID on a ledger? Would the resolver support this capability as well similar to how URLs can redirect?

[talltree]

@kdenhartog I personally would like it to be possible to prove equivalence of two DIDs (meaning that they identify the same DID subject and are controlled by the same DID controller). But I would strongly recommend we try to do that via cryptographic proofs provided in DID documents. We started down that path in the original DID spec but finally decided to put it out of scope to limit complexity. We noted it in the Future Work section.

IMHO it's complex enough that it could be an entire second spec.

[peacekeeper]

This is potentially related to #7, where we are discussing that a service endpoint - instead of containing an endpoint URL - "redirects" to a service endpoint of another DID. In addition to supporting this for a specific service endpoint, such a "redirect" ability could perhaps be supported for an entire DID Document.

[talltree]

@peacekeeper Can you explain in a little more detail how that would work, and what a motivating use case might be (I think I get it, but I want to really have it clear in my mind).

[peacekeeper]

@talltree (everybody else simply ignore this line) I think this is like the Refs we had in XRI - issue #7 is like a Ref on the Service level, whereas this issue here is like a Ref on the XRD level.

For DID Documents, I think it would mean having something like a "ref" or "redirect" on the top level, e.g. like this:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "redirect": "did:elsewhere:xyz01234567"
}

Semantically, we could re-use existing RDF properties such as owl:sameAs or rdfs:seeAlso. Mastodon uses as:movedTo for moving accounts.

As you note, the topic of DID equivalence is covered in the Future Work section.

[kdenhartog]

Sounds like there's some good ideas, and we can pick them back up at a future date. In the case of using a redirect I suspect it will work well for anchoring to multiple ledgers, but in the case of the peer DID case, I'm not sure how this would work. I'm content with closing this issue for now and will reopen it when we want to address this work later.

[peacekeeper]

@kdenhartog I'm curious why you think it wouldn't work for peer DIDs? If you start with a peer DID and then want to anchor it to a ledger, you could include a "redirect" element in the peer DID's DID Document? Or is that different from what you meant?

[talltree]

I agree with Markus that a peer DID should be able to use such a "redirect". I would actually call this something different—like the XDI concept of a "ref" that is a one-way statement of canonical equivalence—because "redirect" is an HTTP concept that does not have the same semantic clarity and weight.

[vongohren]

This is quite interesting thoughts, as a service builder, who dont want to create lockin effect to any ID provider, we wonder how we can, in early stages move the users from dids flexible.