The benefit of pairwise DIDs?


Dear members of the Sovrin forum,

I have some questions on the DPKI aspect of Sovrin.

It seems that in the past there has been a discussion whether to use universal unique DIDs and public keys (for every natural person) or pairwise DIDs and public keys (for every connection between a natural person and an institution). Over the past couple of weeks I have tried to understand those two different cases and what their advantages and disadvantages are, but I am not completely certain whether I understand it well. Below is what I found.

The case with universal unique DIDs:

Potential advantage: A DID and its associated public key can work as a `DPKI certificate’. This enhances the security aspect by providing a secure channel by guaranteeing the authenticity of the public key to a large extent (because a trust anchor is required upon registering).
Potential disadvantage: Whenever the individual discloses the DID or public key to authenticate, its actions can be linked to this DID or public key. This would severely limit the privacy features of the self-sovereign identity management system. In the extreme case this could nullify the privacy-enhancing features given by issuer unlinkability (IU) and multi-show unlinkability (MSU) in the context of attribute-based credentials.

From a privacy perspective, the disadvantage above is the reason why Sovrin decided to switch to pairwise DIDs, correct?

Then the case with pairwise DIDs:

Potential advantage: Unlinkability of DIDs and public keys, therefore not impacting privacy features such as IU and MSU.
Potential disadvantage: The authenticity of the public keys is not guaranteed, right? There is basically a ‘trust on first use’-principle here, right? Wouldn’t this severely limit the guaranteed security? Also, what would in this case be the difference with WhatsApp for instance and their end-to-end-encryption? What is the functional added value by storing the pairwise DIDs on the ledger? Also, wouldn´t using pairwise DIDs significantly increase the amount of traffic on the ledger? I understand that the DID documents contain quite a bit more than just the associated public key which has control over it, such as endpoints and public keys who can perform CRUD operations on the DID documents. But what is the real point of doing that when it is just a pairwise DID? Those public keys to perform CRUD operations should also be unlinkable across different DIDs.

I seem to be missing something crucial here. I hope somebody can explain this to me.

Thanks in advance!

Best regards,



Rick: Excellent, thoughtful question!

I am not a Sovrin spokesman, but I’ve participated in many Sovrin design debates, so I’ll answer from my own perspective and let you decide how well it embodies Sovrin philosophy…

First, I’d revise your first “potential disadvantage” paragraph by saying that the words “In the extreme case” should be replaced with “in the common case, virtually guaranteed to occur”. Privacy loss isn’t potential or theoretical, unless you believe that the Facebook debacle was surprising.

Second, I think your connection later down between pairwise DIDs and “trust-on-first-use” gets to the heart of a misunderstanding. DIDs aren’t supposed to be trusted (in the way I think you assume) because of either their DID value or the keys associated with it. Just because Acme’s website announces to the world that “we do business as DID 12345” doesn’t mean the world should believe it. The website could be hacked at any time. Current PKI that uses X509 certificates assumes that a website is legit if the certificate is provided by the server when the client browses there–but we all know of many cases where hackers take over a site and change content while leaving the cert in place.

Thus, the potential disadvantage you point out for pairwise DIDs isn’t really unique to pairwise DIDs. No DID is trustworthy just because it exists and is backed by a key–not even public ones. DIDs are trustworthy because of what the person on the other side of the connection can prove about themselves, using verifiable credentials and the proofs that derive from them. This is what’s radically different between Sovrin and WhatsApp–the latter doesn’t propose to prove anything, once the encrypted channel is set up. You’re just supposed to trust because of key possession itself (plus WhatsApp’s endorsement of the other party’s contact info, maybe). What the other party says over that encrypted channel can only be assumed to be true.

Sovrin’s proving mechanism is far, far more powerful and flexible than certificates. For example, you can steal a person’s private keys for a DID and still not be able to prove things as them (impersonation), due to a link secret and agent M of N authorizations. You can even steal private keys plus a link secret, and still not be able to impersonate, due to an AuthZ policy. Sovrin supports various recovery mechanisms and revocation mechanism that are way more powerful and privacy-preserving than the familiar and justly maligned cert revocation mechanisms of PKI. This is the DKMS design work you may have heard about, that was developed under a research grant from the US Department of Homeland Security, and that is explorable here until it moves into a more permanent place in Indy or Sovrin:

Pairwise DIDs would significantly increase traffic to the ledger, if they were stored there. But they will be stored in micoledgers instead. Microledgers are also discussed in the link above; they have been announced as a Sovrin feature but are not yet in production. Even without microledgers, Sovrin’s ledger would be able to support pairwise DIDs, however, for many years to come.


A few other points:

  1. Sharing DIDs across relationships (one unique DID used everywhere, or a small handful of DIDs used in a few similar context categories) means you are also sharing keys across relationships. This is essentially like reusing passwords, and is widely acknowledged to be a very bad idea from a cybersecurity perspective. The scope of a hack in such a system is not a single relationship; it’s every relationship that shares that key. And if you have to rotate a key at the request of a remote party, you impact all parties that know you use that key, not just one.

  2. Sharing DIDs across relationships allows correlation, as you’ve noted. (Sometimes the counter-argument is made that “you’ll be correlated anyway.” This is a weaker argument than it sounds like at first blush.) It’s important to note that this concern can’t be dismissed even if you are willing to believe that the remote parties never collude–because any remote party can be hacked. Once hacked, the correlation can be done by a hacker, despite the remote party’s best intentions. And a hacker that knows who you are and that has some PII about you in one context is far more likely to be able to hack you in another context. I believe cybersecurity pundits suggest not having the same username in multiple accounts, if you can avoid it, because of exactly this concern–it makes transitive hacking easier. So correlation isn’t just about esoteric privacy; it also has cybersecurity ramifications.

  3. Sharing DIDs across relationships presupposes that you can put a relationship into the single stable bucket where it belongs with all its similar peers, and keep it there forever–and is thus fragile to relationships that evolve. Suppose Alice uses a common DID for all her online dating, but eventually falls in love with and marries Fred out of that pool. Now she needs Fred to be a special relationship unlike the one with her other online dating connections. Does she create a new DID for Fred, losing the old history? This same evolving relationship phenomenon can occur between institutions and other institutions (a b2b customer becomes a supplier) and between institutions and people (a customer becomes an employee).

  4. Sharing DIDs does not allow you to burn a DID when you want to end a relationship. Back to Alice using a DID for online dating. Suppose Alice wants to show her new husband, Fred, that she will never again use the relationship she used to have with Dylan. In the pairwise model, Alice can set the verkey for the Dylan relationship to null, and she and Fred and Dylan all know that the relationship can never be resurrected. In the shared DID case, Alice can’t burn that shared DID without cancelling all the relationships that share it. (Terminated relationships matter for legal reasons with institutions, so this is not just a personal issue.)

  5. Without pairwise DIDs, models for guardianship and signing authority becomes less granular. Should I as a guardian of my mother who has Alzheimers have different authority with respect to the hospital than I do with respect to her insurance company? If so, I need a different DID. In a corporate context, should an officer of the company have different signing authority in one B2B relationship than it has in another?