Seeking clarification on DIDs and Public keys


At work, we have been having some discussions about what goes on the ledger, and so I have been reviewing the document “What goes on the ledger”, available at:

My understanding is that every “entity” that has an “identity” on sovrin has a logical sw module called an “agent” that operates on that entity’s behalf. To keep things simple, let’s stick to the 4 entities in the demo: Alice, Faber, Acme, and Thrift.
Alice is a single user, so she as an “indy-client-agent”, which is installed on her device. She also has an endpoint where she can be contacted within the sovrin domain.
Faber is a “Trust Anchor”, and so has an endpoint contact URL which is also part of the sovrin overall network. The main difference between Alice and Faber is that Faber can create new identities, which it does for Alice in the demo.
Acme and Thrift are also “Trust Anchors” and can add new identities to the network.

When Alice contacts Faber for the first time, a number of things take place:

  1. Alice “logs in” to the Faber alumni site using some auth method defined by Faber.
  2. Alice receives a connection request from Faber that contains Faber’s name on the network: “Faber College”, Faber’s “DID”, and a nonce, plus a signature over the connection request (as described in the demo).
  3. Alice decides to accept the connection from Faber, and now several things occur:
    a. Alice’s indy-client creates a public/private key pair for Alice to use.
    b. The indy-client creates a DID identifier for Alice.
    c. The indy-client verifies the signature on the connection-request (cr), presumably by contacting the indy network (sandbox), supplying Faber’s DID, and getting Faber’s public key in return, which it uses to verify the signature on the cr. One question here is how does the indy-client get access to the indy-network since Alice is not yet known to the network?
    d. The indy-client gets Faber’s endpoint addr from the DDO that also contained Faber’s public key, so it knows how to contact Faber. (again same ? as in c.)
    e. The indy-client sends the request to Faber, presumably signed by Alice’s private key. Plus the request contains Alice’s new public key and DID created by the indy-client.
  4. Faber receives the request from the indy-client, verifies the sig using Alice’s public key, and then, in its role as Trust Anchor, adds Alice to the indy network, identified by her DID, and with a DDO containing her DID, public key, and maybe a contact address URL.

So, we now have a “synchronized connection” and both Alice and Faber can communicate with each other securely. Faber “knows” who Alice is from her original login and Alice “knows” who Faber is based on her original alumni letter from Faber which provided her w the URL to login as an alumni, and optionally go thru this process to get her transcript.

So, now come the actual questions which this post is about.
First, for context, I am assuming that the following are the key pieces of data:
Faber’s DID, Public Key, and endpoint URL.
Alice’s DID, Public Key, and endpoint URL.
These elements comprise Alice and Faber’s DDO stored on the network, accessible by each’s DID as a reference lookup key.

Now for additional context, let’s get back to that document: “what’s in the ledger?”.

A quote from that document says the following:

"To protect privacy and avoid correlation,
each Identity Owner can have multiple DIDs stored on Sovrin,
and by definition this means they can have multiple verification keys and endpoints.

With Sovrin, each user is able to establish a specific DID
for every relationship that they have.

These are called “pairwise” identifiers and they are tremendously powerful.

They allow an Identity Owner to keep their interactions with one party
completely separate from any other party.

The Identity Owner is the only person able to map and correlate their DIDs.

This means that the relationship a person establishes with their bank
is entirely separate to the one that they establish with a retailer,
so neither bank nor retailer can correlate the Identity Owner’s activities
with each of them."

So, here are the questions:

  1. Will Alice end up with separate DIDs and public keys for each of her connections: i.e. one for Faber, one for Acme, one for Thrift?
  2. Similarly, does Faber identify it self with different DIDs and public keys to each of its users. i.e. Alice, Bob, Charlie, etc.


  1. Does Alice have one DID and public key that she uses with Faber, Acme, and Thrift?
  2. Similarly, does Faber have one DID that it sends to everyone so that Faber only needs to have one public key.

It seems to me that both are possible. However, what I am trying to get at, it what is expected to be the “recommended answers” to these questions.


The strong recommendation from Sovrin is that Alice ends up with separate DIDs and public keys for each connection. So does Faber.

This derives from Sovrin’s stance on privacy; privacy is seriously undermined by public DIDs that are shared with multiple parties. Please see requirement 1 in “Self-Sovereign Privacy by Design” (