How does correlation prevention work in the self-sovereign identity model

Question

The self-sovereign identity model is based on this triangle of trust:

The issuer issues verifiable credentials (VC) to the holder. Then the holder can present those VC to the verifier. Because the verifier trusts the issuer, it will grant the holder access to some service based on those VC.

Each party in this triangle has a dezentralized identifiers (DID). A DID is basically an ID corresponding to a private/public keypair. That way communication between the circles in this triangle is secure and each circle can prove their DID and sign messages.

What I don't understand is the following: In order to prevent correlation, a holder generates a new DID for each verifier that is interacts with. But then the issuer would also need to issue a new VC for that new DID. So a holder has to request VC from the issuer for every single verifier that it interacts with? This is like getting a new drivers license issued every time you need to present it somewhere? Is this really how it's supposed to work?

Answer 1

You've described it very well and the ordinary use case works like that.

One improvement of this model in regards to correlation over the traditional delegated identity providers like Google OpenID/OAuth, is that currently when you click "Sign in with Google" they issue a short-lived id_token which you bring with a redirect to the site where you're trying to login. Which means that every time you login, Google/Azure/etc. - the provider of the id_token knows that you have logged in to that site in that moment. When your local session with that site expires, and the next day you click again "Sign in with Google", Google knows that you've logged in there again, because they issue another short-lived id_token for you.

With VCs, they don't typically expire in a day (although they could) and once you're issued the VC, you can login/access multiple times into other sites with it and the issuer (i.e. Google) will never know that you've used it there - because there's no short-lived tokens which they must generate to approve of your identity/access. It has already been approved once with a long-lived credential in your wallet.

Another useful property and more complicated use case is that you can create more DIDs which are related to the DID which was verified by a trusted issuer. Some people are working on using Zero Knowledge Proofs and in this context it might mean that you can self-issue VCs for these new DIDs and include a ZKP that you have a credential from a trusted issuer, but without revealing the actual initial credential. This way you might use different DIDs for different sites/services, which can be trusted because they carry the ZKP that you're a real person, citizen of a particular country or whatever.

These things are all somewhat experimental, but they seem to have potential. Big players like Google are not very interested and don't push the specs/implementations forward, because decentralized technologies basically work against data aggregation and correlation, which they use heavily for monetization. I think that's another reason for the slow progress and adoption of DIDs and VCs.