Exploring P2P Self-Sovereign Identity Exchange

The following describes two people — Bob and Alice — meeting in person and exchanging information so they can bootstrap a cryptographically verifiable communication channel with one another. They can then use this channel to share identity data with one another in a self-sovereign way. As such, it is also a use case of Self-Sovereign Identity (SSI) technology.

All of this amounts to a fancy way of saying that Alice and Bob will be able to communicate with one another, knowing that the person they're communicating with is in fact the other person, and knowing that no one can eavesdrop on their communication.

‍

Before we start

In order for Alice and Bob to bootstrap this secure channel, we need both of them to have an SSI mobile wallet app installed (although they don't need to install the same one, as long as both apps comply with SSI standards).

‍

Step 1: Alice produces a connection invitation

Alice meets Bob in person and wants to establish a secure connection. She opens up her SSI wallet app and instructs the software — her "edge agent" — to generate a connection invitation specific to Bob.

Behind the scenes her edge agent will generate a random number — a nonce — to uniquely identify this invitation in order to prevent others from re-using it later. This nonce is included together with the address of Alice's service endpoint (for Bob to know where to send his message to).

Step 2: Bob Scans the QR code

Bob uses his SSI wallet app to scan Alice's QR code. As soon as the app recognizes that this is a new connection invitation, it genereates the following:

1. A unique public/private key pair, and
2. A peer Decentralized ID (DID) based on this public/private key pair.

This peer DID is a private pairwise pseudonymous identifier that will be used to identify Bob's unique connection to Alice in a privacy preserving way that only the two of them know about.

These values are then stored in Bob's wallet.

Step 3: Bob's wallet sends a connection request message

Once the key pair and peer DID are saved in Bob's wallet, his edge agent composes a connection request message that includes a so-called DID Document.

This DID document is prepared exclusively for Alice and it includes the following information:

1. The new peer DID
2. Bob's public key
3. Bob's service endpoint

Bob's edge agent sends this connection request message to his cloud agent — a piece of helper software specific to Bob, running in the cloud — with instructions to forward it to Alice's cloud agent via the encrypted channel established through the service endpoint Alice specified in her connection invitation.

Step 4: Alice confirms the connection

Alice's cloud agent receives the connection request and pushes it to her edge agent. Once received by her edge agent, it will prompt Alice with a dialog asking if she would like to accept Bob's connection request.

Once she accepts, the edge agent will save Bob's connection information in Alice's wallet for future use.

Step 5: Alice's edge agent prepares a connection response

Now Alice's edge agent does the same thing Bob's edge agent did: it generates a new and unique public/private key pair and a peer DID that will be known only to Bob. It then saves these in her wallet.

Step 6: Alice generates a connection response

Alice's edge agent now creates a connection response message that includes a DID Document containing:

1. Her own peer DID
2. Her public key
3. Her service endpoint

Alice's edge agent can encrypt this message using the public key from Bob's DID document so that only Bob can read it. And it can be sent to the private service endpoint that Bob specified for Alice to use.

Alice can also use this message to update the service endpoint and/or keys that Bob originally used for her. This enables Alice and Bob to move away from the unencrypted channel they were using to communicate initially.

Once it's ready, Alice's edge agent send her connection response to her own cloud agent with instructions to forward it to the private service endpoint that Bob's agent forwarded to Alice.

Step 7: Bob Receives Alice's connection response

Bob's cloud agent forwards the connection response to Bob's edge agent which saves the DID document describing Alice's half of the peer DID connection information in Bob's wallet. Bob's edge agent notifies Bob that the connection is now complete in both directions.

With that, the connection is established until either one of the parties decides to terminate it. They can now use this connection to exchange identity information in a self-sovereign way.

‍

References

[1] Preukschat, Alex, and Drummond Reed. 2021. Self-Sovereign Identity: Decentralized Digital Identity and Verifiable Credentials. Simon and Schuster.

[2] “Peer DID Method Specification.” n.d. Accessed June 8, 2021. https://identity.foundation/peer-did-method-spec/.