What happens to the VCs after a DID move or change

[vongohren]

I have this issue: https://github.com/decentralized-identity/interoperability/issues/25 which is more around the DID and how that can be portable and how to do it.

Then I have another issue of interoperability/portability. That is what happens to the VCs after you are deemed necessary to move to another did, because did:x became unsafe, or you want some other mechanisms offered at that DID?

First case: All your VCs, you are still in possession of, but the subject of that VC is the did you have decided to no longer use. What are the right way of proving control over these VCs?

You can wrap it all in a presentation with your new DID method, and sign it. Which proves you are in possession. But it does not prove the rightful ownership of those VCs? Is this where, before you move a DID, you do a self issuing VC, renouncing all your VCs to that new DID? So you can build a chain of trust? How do you even model this?

Second case: You lose control of the DID because of the unsafe ledger was taken over. But not the VCs. Is this a completely different case where recovery mechanisms and other stuff come into play? Or is this also a play where you simply have a way of saying that this new DID control these VCs? I see the implications in the matter that if I'm to prove I had control over an identifier, I would need some data points for that person to trust that this new DID is the same person.

I believe the first case is solvable but would like to hear what you guys think about best practices around that. Second case I'm more in the shadows about.

[brentzundel]

Many VCs use DIDs as the primary means of binding the VC to a particular holder. The holder proves control of the DID and thereby proves the VC is bound to them. While using DIDs as a holder binding mechanism is certainly convenient, it does lead to the problems you outline. The simplest answer to your first case is to seek re-issuance of the VCs to the new DID. You would be correct in wondering what to do in the event that re-issuance isn't an option. In that event, we enter into the same possible fixes as could help with your second case. There would need to be some established mechanism for chaining trust in that initial DID to some other DID. The trouble with such a mechanism is that if a DID is compromised, what is there to prevent the attacker from making use of the chaining mechanism to point your VCs to a DID they control? One option is to not use DIDs as the holder binding mechanism at all. CL signatures, and BBS+ signatures with anonymous credentials make use of a link secret to bind the issued credential to a particular holder. While these signature types feature a link secret as the primary mechanism for holder binding, there is no reason the link secret holder binding couldn't be made generic enough for use in any verifiable credential. Of course there are some trade-offs to this approach as well.

[vongohren]

I see and yes there are many complicated case. But in a reissunace case, have you guys done this before? In an automated manner? Would you store the resissuance link in the VC or is there a paper on this somewhere?

Because what it means in our case, is that the issuance happens when a person signs of the credentials. Meaning clicking a button, and signing scanning a QR code. But maybe our process is just old fashion and we can see to revamp it to be able to reissue to a new did at some point.

But all the other concerns you are rasing, are also things I wonder how would be possible. Do you have some concrete place to read more about CL signatures and BBS+ @brentzundel ? This is new to me

[brentzundel]

This is a pretty good explainer on CL Signatures and anonymous credentials in general. I have more, if you're interested.

[vongohren]

@brentzundel sweet, thanks. Let me start there and I can ping!