Drummond Reed, Alex Preukschat, and Daniel Hardman

Daniel Hardman, former chief architect and CISO at Evernym and now principal ecosystem engineer at SICPA, has been designing SSI infrastructure since before it was called SSI. He has seen firsthand in the market multiple instances of the basic SSI interaction patterns that we describe in this chapter.

In chapter 2, we examined the core building blocks of self-sovereign identity (SSI). In this chapter, we show you how these building blocks are put together to implement SSI using seven example scenarios that progress from the relatively simple to the reasonably complex. Our objective is to show you how the SSI digital identity model works differently than the centralized or federated digital identity models.

The scenarios we have chosen are as follows:

1. Alice and Bob form a connection after meeting in person at a conference.

2. Alice and Bob form a connection via Alice’s blog.

3. Bob logs in to Alice’s blog to leave a comment.

4. Alice and Bob form a connection by meeting through an online dating site.

5. Alice applies for a bank account.

6. Alice buys a car.

7. Alice sells the car to Bob.

Our example scenarios use the Alice and Bob characters that have become so iconic in cryptography and cybersecurity that there is an entire Wikipedia article about them (https://en.wikipedia.org/wiki/Alice_and_Bob). Each scenario illustrates a basic pattern of SSI usage that you will see repeated in the industry-specific SSI scenarios we explore in part 4 of this book.

3.1 A simple notation for SSI scenario diagrams

In this chapter, we will use the simple diagramming notation shown in figure 3.1. These 11 icons are all that is needed to show how the concepts of SSI digital credentials can be applied to a myriad of trust problems we encounter as consumers and businesses every day. Most of these icons are self-explanatory, but here is a key:

• Person —An individual SSI identity holder (e.g., Alice and Bob)

• Organization —An organization or group that holds an SSI identity

• Thing —A physical, logical, or natural object with an SSI identity (e.g., a device on the Internet of Things [IoT])

• Edge agent and wallet —The device and software used by a person or organization to store, manage, and share their SSI digital credentials (see chapters 2 and 9)

• Cloud agent and wallet —The same as an edge agent but operating in the cloud

• QR code (quick response code) —A two-dimensional barcode that can be read by the camera on a smartphone, tablet, or other computing device to initiate an interaction

• Initiation —The first step in forming a digital identity relationship between any two SSI identity holders (e.g., Alice and Bob)

• Connection —A relationship established by consent between two SSI digital identity holders whose agents exchange cryptographic keys with each other to form a secure, private communications channel

• Credential —A verifiable digital identity credential (see chapters 2 and 7)

• Proof —A digitally signed, cryptographically verifiable proof of specific information from a credential

• Verification —The result of an agent successfully verifying a proof

Figure 3.1 The simple set of icons we use for the SSI scenario diagrams in this chapter

In all of these scenarios, we also use the three fundamental roles—issuer, holder, and verifier—from the verifiable credentials trust triangle introduced in chapter 2 (figure 3.2).

Figure 3.2 The three core roles in the verifiable credential trust triangle

3.2 Scenario 1: Bob meets Alice at a conference

All forms of digital identity exist in the context of a relationship of some kind. In typical enterprise identity and access management (IAM) scenarios, this might be the relationship between an employee and a company, or a consumer and a website. Or, in an IoT context, it might be the relationship between an IoT device and its manufacturer or owner.

All of these scenarios are typical client-server relationships, where the identity holder is using client software such as a browser to establish an identity with (register) and authenticate to (log in) a server controlled by an enterprise. This classic account-based identity pattern uses either the centralized or federated identity model described in chapter 1.

The SSI identity model is broader. It is based on peer-to-peer relationships between any two entities, of which client-server relationships are just one kind. To emphasize this, the first scenario we will run through is one of the most common interactions in business: Alice and Bob meeting each other at a conference and exchanging business cards. In a scenario like this,

• Neither Alice nor Bob is a “client” of the other. They are simply peers.

• Neither Alice nor Bob is running “servers.”

• Neither of them is creating an “account” with the other—rather, they are just forming a connection between peers.

In the pre-digital days, this simple peer-to-peer exchange might have looked like figure 3.3.

However, at today’s business conferences, the connection is often made digitally, using mobile phones and business networks like LinkedIn. So the ceremony now looks more like figure 3.4.

Figure 3.3 The pre-digital ritual of forming a business connection by exchanging business cards

Figure 3.4 The digital ritual of exchanging business card info using mobile phones and LinkedIn

The digital version of this ritual doesn’t just eliminate paper; it puts the contact info directly where it is most useful: on your mobile phone. Even better, if the connection is made through a business network like LinkedIn, the connection will persist even if Alice and Bob change jobs, email addresses, or phone numbers. However, this convenience comes at a cost: sharing all your professional contact information with LinkedIn. For many of us, this is not an issue—the discomfort about privacy is offset by convenience. However, for others whose professional networks are confidential or security-sensitive, using a public social network like LinkedIn, Facebook, or Twitter is not an option.

What if Alice and Bob had an easy, fast way to form their own connection, directly, peer-to-peer, without the need for any intermediary? What if this connection created a secure private channel that only Alice and Bob could use? And what if this connection could last forever—or until either Alice or Bob (or both) decided they did not want it any more?

With the SSI building blocks we introduced in chapter 2, we can build this connection in a fully decentralized manner that does not need to rely on any central party. The actual ceremony depends on the specific capabilities of Alice’s and Bob’s smart-

phones and agents. But one popular option—scanning a QR code—is familiar to anyone who has ever used a mobile boarding pass to board a plane (figure 3.5).

Figure 3.5 Forming a new SSI connection can be as easy as scanning a QR code.

Some people are already printing QR codes on their business cards to make it easier to connect with them. But those QR codes usually take you to a centralized service provider like LinkedIn that forms the connection on the service provider’s proprietary network.

With SSI, you are creating a connection without using any intermediate service provider or proprietary network. Alice and Bob are connecting the wallets and agents on their phones directly, cryptographically, so the connection is entirely private to the two of them. It doesn’t matter whether Alice scans Bob’s QR code or Bob scans Alice’s. Either way, once both Alice and Bob approve it, a direct, private, peer-to-peer SSI connection is created between their two agents, as shown in figure 3.6.

Figure 3.6 A simple connection between Alice and Bob, implemented by their respective agents

Using SSI to establish connections without intermediaries has deep implications for the future of communication and trust between people. When an intermediary is no longer needed, all of the terms and conditions and limitations imposed by that intermediary disappear. The two peers are free to structure the relationship, establish trust, and negotiate data exchange any way that works best for them—all of which were goals of the early internet. So in many ways, SSI is just helping us re-establish the original decentralized vision of the internet itself.

Of course, figure 3.6 is an over-simplification. It doesn’t show the specific hardware and networks being used or the DIDs and DID documents being exchanged. But conceptually, it is an accurate picture of what exists after Alice and Bob have created their connection.

What’s going on under the hood For more technically minded readers, the following figure takes this scenario down another level of detail. Feel free to skip this sidebar if you don’t need the technical minutiae. A more detailed view of how the connection is formed between Alice and Bob, showing communications between the edge agents (on Alice’s and Bob’s respective smartphones) and the cloud agents hosted at Alice’s and Bob’s respective agencies. First, let’s explain how Alice and Bob are each provisioned with the edge agents/wallets and cloud agents shown in the figure. They begin by downloading an SSI mobile wallet app (or using one that comes installed on their smartphone). Just as with browsers and email apps, it should not matter whether Alice and Bob both use the same mobile wallet app, as long as their apps support the open standards for SSI interoperability (see chapter 5). The first time Alice and Bob open their respective mobile wallet apps, their edge agent software should prompt them to set up a cloud agent. This is similar to setting up your smartphone to use a cloud backup service. Different apps will work with different cloud agent service providers—called SSI agencies—who offer the service of hosting cloud agents. This should take less than a minute and only has to be done once. (Once your edge agent is paired with a cloud agent, it should continue to work seamlessly unless you decide to break the connection and pair with a different cloud agent.) Once Alice and Bob have their mobile wallets, edge agents, and cloud agents set up, this is how the scenario proceeds (assuming that it is Alice who produces a QR code for Bob to scan—the scenario works the same way in reverse if Bob produces the QR code). Alice produces a QR code. Alice clicks a menu option in her mobile wallet app (edge agent) to cause it to generate a QR code for a new connection called a connection invitation. This request includes information about how Bob’s agent can reliably contact her over an encrypted channel. The data in this QR code is not secret and does not need strong security guarantees; the encrypted channel adds those guarantees later in the flow. Before it generates the QR code, Alice’s edge agent generates a nonce—a random number used for security—and sends it to Alice’s cloud agent to notify it to expect a message associated with that nonce. This nonce is included in the QR code, making the QR code unique to Bob. When Alice forms her next connection with Carol, for example, the QR code will be different. Bob uses his mobile wallet app to scan the QR code. As soon as Bob’s edge agent recognizes that this is a new connection invitation, it instructs the wallet to generate the following: A unique new public/private key pair (see chapter 6 for more details about the underlying cryptography). A peer 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. Once the key pair and peer DID are saved in Bob’s wallet, his edge agent composes a connection request message that includes a DID document (the file of metadata that goes with each DID—see chapters 2 and 8). This DID document is prepared exclusively for Alice: it includes the new peer DID, the corresponding public key, and the private network address of Bob’s cloud agent (called a service endpoint because that’s how other agents can “call” Bob’s agent to send a message). Bob’s edge agent sends his connection request message to Bob’s cloud agent with instructions to forward it to Alice’s cloud agent via the encrypted channel Alice identified in her connection invitation. The ball is back in Alice’s court. Alice’s cloud agent receives the message from Bob’s agent and pushes it to Alice’s edge agent, asking if Alice wants to confirm the connection. Alice’s edge agent prompts Alice to confirm the connection. Alice clicks Yes, and her edge agent saves Bob’s half of the connection information in its wallet. Now Alice’s edge agent does the same thing Bob’s did: generates a unique new public/private key pair and a peer DID known only to Bob. It saves these in her wallet and creates a connection response that is the mirror image of Bob’s connection request: it contains Alice’s peer DID, public key, and service endpoints for the connection. 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. Best of all, Alice’s edge agent can use this message to update the service endpoint and/or keys that Bob originally used for her. This enables the insecure information from the connection invitation to be replaced with new secure information safe from any eavesdropper. Once it is ready, Alice’s edge agent sends her connection response to her cloud agent with instructions to forward it to the private service endpoint that Bob’s agent gave Alice. Bob’s agents take the final step to complete the connection. 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. Now Alice and Bob have a permanent, private connection they can use for cryptographically secure communications of any kind. A few more notes about this: No verifiable credentials had to be exchanged for Alice and Bob to begin trusting each other because this connection was formed in person. This doesn’t mean some type of credential exchange won’t be needed in the future—for example, if they are going to do a high-stakes business deal—but right now, they have sufficient trust. No interactions were needed with a public ledger or blockchain. The whole process took place using peer DIDs and DID documents that were generated and exchanged completely off-chain—good for both privacy and scalability. Public DIDs registered on a public blockchain are generally only needed for issuers of credentials that anyone needs to be able to verify. The connection is completely private and known only to Alice and Bob. No intermediary service providers were involved except to host cloud agents and deliver encrypted messages. Those cloud agent hosting providers (agencies) only know that there was traffic between two agents. They can’t “see” inside the messages to know who was talking to whom about what. (This can be further privacy-protected by using onion routing between agents.) If either Alice or Bob (or both) changes their cloud agent, the connection moves with them. Their respective agents just send the other an update to their connection information with the new private cloud agent address at the new agency. This connection invitation flow can work anywhere. It does not require a pre-established secure channel; nor does the recipient of an invitation need to know anything about SSI, DIDs, or mobile wallets. So it is one way SSI can grow “virally” without any centralized company or network pushing it.

3.3 Scenario 2: Bob meets Alice through her online blog

This scenario also results in Alice and Bob forming a connection. But this time they don’t meet in person. Rather, Bob discovers Alice’s blog about her state-of-the-art website design business. Bob likes the content there and decides he’d like to contact Alice about creating a website for him.

Alice, being a cutting-edge web designer, has SSI-enabled her blog so that it can accept connection requests from visitors who want to connect directly with Alice. To do this, she adds a cloud agent to her blog and connects it to her edge agent (see the following sidebar if you are interested in the details). Because this is Alice’s personal blog, this cloud agent acts as another representative of Alice as an individual: it doesn’t represent her blog as a separate “thing.” This illustrates a key principle of SSI: Alice can have as many agents as she wants, on as many devices or web locations as she wants, each of which allows Alice to express her identity and form new relationships in a specific context: in this case, her online presence as a web designer.

note If she wanted to, Alice could set up her blog to have its own independent SSI identity so that visitors could form connections directly to the blog instead of to Alice the person. See the following sidebar for more information.

Figure 3.7 shows the agents and connections established in this scenario. The numbers indicate the order in which actions are taken.

Figure 3.7 The scenario of Bob meeting Alice by first reading her blog and then deciding to request a connection with her by scanning a QR code on her blog

The scenario begins with Bob deciding to request a connection via Alice’s blog:

1. Bob uses his edge agent to scan the QR code for the connection invitation. This QR code is configured by the SSI plug-in that Alice installed for her blog (see the following sidebar for details).

2. Bob’s edge agent app prompts him to accept the connection invitation. When Bob presses Yes, his edge agent generates the key pair, peer DID, and DID document for the connection request message as described in the preceding sidebar and sends it to Bob’s cloud agent to forward it to Alice’s cloud agent to forward to Alice’s edge agent.

3. Alice receives the connection request and approves it. The rest of this scenario proceeds as in the preceding one: Alice’s edge agent generates her key pair, peer DID, and DID document for the connection response message, which is then sent back via the cloud agents to Bob’s edge agent, where it is stored to complete the connection.

Note that, as with scenario 1, this scenario does not require any exchange of verifiable credentials. If Alice is willing to accept connection requests from readers of her blog, her agent does not need to ask for any further identity information. But this also exposes Alice to receiving spam connection requests. To guard against these, Alice’s edge agent can require proofs of one or more common verifiable credentials that Alice trusts. This is described further in scenario 4.

What’s going on under the hood Alice hosts her blog on WordPress, so we’ll assume WordPress has an SSI plug-in. (Such a Wordpress plug-in is under development as this book is being written.) When Alice installs this plug-in, it shows her a QR code needed to set up her cloud agent. Alice uses the edge agent app on her phone to scan the QR code. Her edge agent app then prompts her to approve setting up a cloud agent for her blog. When Alice says yes, the edge agent sends a message to Alice’s existing cloud agent (the figure in the previous sidebar) requesting a) to provision the new blog cloud agent, and b) to form a connection between it and Alice’s edge agent. When finished, Alice’s existing cloud agent sends a connection response to Alice’s edge agent with the peer DID and DID document containing the private network address and public key for encrypted communications with her new blog cloud agent. Now Alice’s blog has a new feature: the ability to display a unique QR code to any reader who wants to request a new connection with Alice. Note that this process works the same way for any SSI-enabled online resource that Alice might want to have an agent for: her LinkedIn page, her Facebook page, a website she has designed, even the signature on her emails. It can also work for anything offline for which Alice wants to set up an agent, such as her business card or the placard for one of her paintings hanging in a local gallery. What if Alice wants her blog to have its own set of connections? In the scenario we just described, we assumed Alice wants her blog to act as another of her personal agents. But what if she wanted her blog to stand by itself: for example, as a portfolio of her artwork from which visitors could order prints? In this case, visitors who requested a connection would receive a connection directly to Alice’s blog as a “thing” and not to Alice as a person. Alice would still control the cloud agent for this “thing”—which from a legal standpoint might represent her sole proprietorship as an artist—but that cloud agent would be separate from Alice’s personal agents that represent her as an individual. Ideally, an SSI plug-in will give a blog owner the choice of how to configure a cloud agent: to represent a person or to represent a thing.

3.4 Scenario 3: Bob logs in to Alice’s blog to leave a comment

Once Bob has a connection with Alice, Bob can use that connection to authenticate himself to Alice at any time. For example, if Bob later returns to Alice’s blog and wants

to leave a comment, Bob does not need to create an “account” with Alice’s blog. His connection is the account. So not only does Bob not need to create a new username and password for Alice’s blog, he’ll never have to remember them!

Figure 3.8 Bob uses a similar pattern to “log in” whenever he returns to Alice’s blog to leave a comment on one of her new posts.

Called passwordless login (or auto-authentication), this is one of the headline features of SSI (see the complete roster of major SSI features and benefits in chapter 4). It works the same way for any SSI-enabled website or application. Figure 3.8 shows the basic sequence:

1. Alice’s blog generates a QR code. Just as in scenario 2, the first step is for Alice’s blog to generate a QR code for a reader to scan if they need to authenticate (e.g., leave a comment or do anything else that requires authorization). This time, when Bob scans the QR code, his edge agent recognizes that Bob already has a connection with Alice. So Bob’s edge agent asks Bob to confirm that he wants to authenticate (or, if Bob has told his edge agent to skip those kinds of confirmations, his edge agent will just proceed).

2. Bob’s edge agent generates, signs, and sends a proof. This proof is signed with the private key in Bob’s mobile wallet for this private peer DID connection only. The proof is then sent to his cloud agent to forward to the cloud agent for Alice’s blog.

3. Alice’s blog cloud agent receives and verifies the proof. It verifies the signature using the public key it has for her private connection with Bob (shared by Bob when the connection was formed—and updated by Bob whenever his edge agent rotates his encryption keys). If the signature verifies, Bob is “logged in.”

What is particularly powerful about auto-authentication is that it can be “tuned” to request the level of authentication a verifier requires for a particular transaction. For example, leaving a comment on a blog is a relatively low-risk activity, so it is enough for Bob to prove he has the private key for the connection (which only Bob knows). But if Bob was asking his credit union to make a $100,000 transaction, the QR code produced by the credit union could request a much stronger proof that this is really Bob.

SSI agents can also produce the authentication tokens needed for other web authentication protocols like OpenID Connect and WebAuthn. For more details, see chapter 5.

3.5 Scenario 4: Bob meets Alice through an online dating site

This scenario will result in Alice and Bob forming a connection just like the one created in scenarios 1 and 2. But this time, the introduction will come via an intermediary matchmaker: an online dating site. Since neither Alice nor Bob has a pre-established trust relationship, this is our first scenario that will require a verifiable credential.

IMPORTANT While the scenarios in this chapter use government-issued ID credentials for illustration purposes, there is no requirement for SSI infrastructure to use government ID credentials—or any other specific type of credential, for that matter. In the end, the verifiers determine what types of credentials they will accept for what purposes. Government-issued ID credentials are simply a widely understood and accepted type of credential.

Figure 3.9 The scenario of Alice and Bob meeting through an online dating site, and Bob proving his authenticity to Alice over their newly formed connection.

Figure 3.9 is a diagram of the steps involved:

1. Bob connects to a Government ID Agency. Bob knows the Dating Site requires proof of identity from an issuer it trusts, and one option is a government-issued ID credential. So Bob first forms a connection with the Government ID Agency cloud agent by scanning a QR code on its website as described in scenario 2.

2. Bob requests a Government ID credential. Bob’s edge agent prompts him for the data (or other steps he must take) to prove his identity to the Government ID Agency (which could involve the Agency requesting proofs of other verifiable credentials from Bob). Once Bob meets the Agency’s policies for issuing a new Government ID credential, the Agency sends the credential to Bob’s edge agent to store in Bob’s wallet.

3. Bob connects to the Dating Site as per scenario 2.

4. The Dating Site requests proof of Bob’s Government ID credential. Bob scans a QR code requesting a proof of the Government ID credential. Bob’s edge agent prompts Bob to approve sending the proof. Bob agrees, and his edge agent generates the proof, signs it with the private key for this connection, and sends it to the Dating Site’s cloud agent. The Dating Site’s cloud agent verifies the proof by looking up the DID of the Government ID Agency on a public blockchain such as Bitcoin, Ethereum, or Sovrin to retrieve the DID document with the public key. If the proof verifies, Bob is good to go to use the Dating Site.

5. Alice joins the Dating Site by forming a connection the same way. The Dating Site may or may not require Alice to send proof of a credential (not shown in figure 3.9). Alice then shares some profile data (which, if already stored in other credentials she has in her wallet, could be sent in a proof from her edge agent).

6. Bob requests a connection with Alice. Bob discovers Alice’s profile on the Dating Site and requests a connection by scanning a QR code—just as he would have done via her blog in scenario 2. But this is a different context, so Alice is more cautious. Her edge agent requires Bob to share a proof of his Government ID credential. Note that Alice could rely on the fact that the Dating Site already has a policy requiring a male member to provide proof of a Government ID credential. But with SSI, Alice can request that proof directly from Bob. She doesn’t have to worry if the Dating Site is not screening members properly.

7. Bob sends Alice proof of his Government ID credential. Bob can do this in one click because his edge agent does all the work. Alice’s edge agent receives the proof over the private connection it set up with Bob and verifies the proof just like the Dating Site did. If it verifies, Alice accepts the new connection. If it fails, Alice’s edge agent can delete the connection immediately without ever needing to bother Alice. Her edge agent is effectively serving as Alice’s protector to make sure that any suitor meets Alice’s minimum verification requirements.

What is even more powerful is that with SSI, Alice isn’t constrained to live with only the filters supported by the Dating Site. Alice can request whatever proofs she wants from her suitors—and her suitors must supply those proofs before they ever even get to “knock on Alice’s door,” so to speak. This could significantly change the online dating ecosystem in a way that increases trust for everyone involved.

3.6 Scenario 5: Alice applies for a new bank account

The next scenario is such a clear business case for the value of verifiable credentials that in October 2018, four companies collaborated to demonstrate how it works in a video called “Job-Creds” [1]. The video shows how Alice first obtains a government ID credential from a driving licensing agency and then an employment credential from her employer (IBM) to finally apply for a bank account. Figure 3.10 shows the complete set of connections and interactions:

Figure 3.10 The set of proofs Alice is asked to provide in order to be issued the credentials she needs (a Government ID and proof of employment) to qualify for a bank account

1. Alice connects with the Government ID Agency, which requests proof of her identity. This assumes Alice already has a mobile wallet and some credentials the Government ID agency will accept, such as a utility account or a student ID.

2. Alice receives her Government ID credential. Once the Government ID Agency has verified Alice’s proofs and validated that they satisfy the Government’s policies for issuing an ID credential, the credential is issued to Alice’s edge agent.

3. Alice connects with her Employer, which requests proof of her Government ID credential. This step is typically performed as part of onboarding Alice as a new employee (required by law in some jurisdictions). Employers can save money by doing it digitally (see section 4.2).

4. Alice receives her Employment credential. Once the Employer’s onboarding policies are satisfied, the Employer issues Alice her new Employment credential.

5. Alice connects with the Bank where she wants to open a new account. Note that Alice could do this by scanning a QR code anywhere she might encounter an invitation from the Bank: on a bus, in a subway, in a newspaper advertisement, in an email, on the Bank’s website, or others.

It’s important to note that in this step, Alice’s agent should first request proof of the Bank’s credentials. The fact that connections are fundamentally bidirectional is how SSI infrastructure can protect against spoofing and phishing attempts. Once Alice has confirmed this is the real Bank and completes setting up the connection, she will never need to worry about being spoofed or phished over that connection because only the Bank will be able to use it to send her messages, and each message will be signed by the Bank’s private key which only the Bank controls.

1. Alice sends a proof of her Government ID credential and her Employment credential to the Bank. These are the two proofs the Bank requires to open a new account. But for Alice, it is just a single step: when her edge agent prompts Alice for approval, she clicks Send, and her edge agent takes care of the rest.

2. Alice receives her Bank Account credential. The Bank’s cloud agent verifies both of the proofs sent by Alice’s edge agent. If they verify, it completes the all-digital process of provisioning a new account and sends Alice her new Bank Account credential.

Now Alice has a new bank account, and the Bank has a new customer. From the point at which Alice has her Government ID and Employment credentials, this process of onboarding a new bank customer, which normally requires an in-person visit and several person-hours of time, can be performed entirely digitally in under a minute. And the result is more secure than the equivalent offline process, because all the credentials can be immediately verified using strong cryptography instead of bank employees trying to verify paper or plastic credentials that are orders of magnitude easier to fake.

3.7 Scenario 6: Alice buys a car

Armed with her new credentials, Alice can now simplify and automate many other kinds of transactions, to the benefit of both herself and the businesses and agencies she interacts with. Figure 3.11 shows the process of Alice buying a new car. In this scenario, we’ll assume the following:

• Alice already has connections with her Bank, Auto Dealer, and Licensing Agency.

• She has picked out the car and negotiated the price with the Auto Dealer.

• She has qualified for a car loan from her Bank.

Figure 3.11 Alice buys and registers a car entirely using digital connections and credentials. In the final step, Alice proves her ownership of the car to unlock and drive it away.

Here are the steps Alice takes:

1. Alice proves her identity to her Bank to request a loan. Because this is a major purchase, the Bank requests one or more other credentials (such as her Government ID) to make sure it is really Alice asking for the loan.

2. Alice receives a Loan credential and Payment Authorization credential from her Bank. Alice can use the Loan credential to prove she has been authorized to receive the loan; she can use the Payment Authorization credential to pay the Auto Dealer.

3. Alice completes the purchase of the car from the Auto Dealer. Alice sends proof of her Payment Authorization credential to the Auto Dealer, which arranges for payment (although not shown in figure 3.11, this process could also use an SSI connection between the Auto Dealer and Alice’s Bank).

4. Alice receives her Purchase Receipt credential from the Auto Dealer. This is an example of a digital receipt delivered in the form of a verifiable credential: a powerful new tool for both consumers and merchants everywhere (see chapter 4).

5. Alice applies to the Licensing Agency to register her new car. Alice presents a proof of her Purchase Receipt credential for the car and a proof of her Loan credential from her Bank. Between them, they contain all the information—including the vehicle identification number (VIN)—that the Licensing Agency needs to issue Alice a Vehicle Registration credential for the car that includes a lien to Alice’s Bank.

6. Alice receives her Vehicle Registration credential. This goes straight into her digital wallet along with all her other credentials.

7. Alice forms a connection with her new car. This is an example of Alice connecting with a thing (as in the Internet of Things) instead of a person or an organization. It works just like our earlier examples, except in this case, Alice scans a QR code on the car (for example, on a window sticker or the car’s digital display).

8. Alice proves her ownership of the car. The QR code requests proof of a Vehicle Registration credential: not just for any car, but for that car, with that specific VIN. That is exactly what Alice was issued by the Licensing Authority, so Alice’s edge agent sends it to the car’s edge agent (operating as part of the car’s onboard computer). Once the car’s edge agent verifies the proof, the car unlocks, and Alice can drive it away.

Although that final step might seem like a scene from a sci-fi movie, it is very real. In March 2018, one of the authors of this book gave a demonstration to the R&D division of the U.S. Department of Homeland Security of unlocking a car using a verifiable credential. As we move toward all-electric cars, onboard computers, and autonomous vehicles, the key to your car of the future could well be a verifiable credential on your smartphone. (This would also make it easy to “delegate” car keys to family members, friends, etc. without having to make physical copies. And these digital “keys” can even be time- or usage-restricted: a child could be given a key to take the car for a trip to the movies but not to drive outside of town.)

3.8 Scenario 7: Alice sells the car to Bob

In our final example, we pull together all our previous scenarios and show one involving person-to-person, person-to-business, and person-to-thing relationships: Alice selling the car she bought in scenario 6 to Bob (whom she met through scenario 1, 2, or 4). There are enough steps that we’ll break this example into two diagrams to make it easier to follow. Part A—the financial arrangements—is shown in figure 3.12. This scenario assumes the following:

• Bob and Alice have already formed a connection and negotiated a price for the car.

• Bob has been approved for a car loan by his Credit Union.

• Bob and Alice both live in a jurisdiction served by the same Licensing Agency.

Figure 3.12 Part A of the scenario shows the steps Bob and Alice take to make the financial arrangements for Bob to buy the car.

The steps in part A are as follows:

1. Bob proves his identity to his Credit Union to request a loan. This the same first step Alice took in scenario 6.

2. Bob receives a Loan credential and a Payment Authorization credential from his Credit Union. Again, this is the mirror of what Alice did in scenario 6.

3. Bob sends proof of his Payment Authorization to Alice. Now Alice just needs to complete her side of the deal.

4. Alice forwards her proof of the Payment Authorization credential to her Bank. She also sends a proof of the Loan Credential she wants the payment applied to. Alice’s Bank uses these proofs to arrange for payment directly from Bob’s Bank.

5. Alice receives an update to her Loan Credential showing that the loan is paid off. Alice can use this revised credential not just to transfer the car registration in part B, but to prove her credit history to anyone else in the future. Note that Alice can now do this without needing to rely on a centralized credit rating agency.

   Part B (figure 3.13) shows the remaining steps to transfer the car title and registration:

   
   

   Figure 3.13 Part B of the scenario shows the steps Alice and Bob need to take to transfer the title and registration for the car.

6. Alice sends proof of her updated Loan Credential to the Licensing Agency. This proves that Alice’s Bank has released its lien and Alice is free to sell the car.

7. Alice receives an updated Vehicle Registration credential from the Licensing Agency. Now Alice is ready to complete the sale to Bob.

8. Alice sends Bob a Purchase Receipt and a proof of her updated Vehicle Registration credential. These are the two digital artifacts Bob needs from Alice to apply for his own new vehicle registration.

9. Bob applies to the Licensing Agency to register his new car. Like Alice in scenario 6, Bob sends a proof of his Purchase Receipt and a proof of his Loan credential. Bob also forwards Alice’s proof of her Vehicle Registration credential. The Licensing Agency verifies all proofs to confirm that Alice owns the car free and clear, that she has sold it to Bob, and that Bob has a loan from his Credit Union to buy it.

10. Bob receives his Vehicle Registration credential. At the same time, the Licensing Agency revokes Alice’s Vehicle Registration credential, so her virtual “key” to the car stops working as soon as the car’s edge agent detects that Alice’s Vehicle Registration Credential has been revoked (for more on how credential revocation works, see chapter 5).

11. Bob connects to and unlocks his new car. This is the same step Alice took at the end of scenario 6, only now Bob is the proud new owner.

3.9 Scenario summary

This chapter took the SSI building blocks in chapter 2 and put them together to illustrate a variety of common scenarios requiring identity and trust.

• To understand white-collar crime, a detective’s mantra is “follow the money.” To understand how SSI works, the mantra is “follow the credentials and proofs.”

• All that’s needed to understand the basic technical flows is to map out the actors that need to establish trust (people, organizations, things), assign them agents (edge and/or cloud), establish the connections between them, and then issue credentials and present proofs to meet all the trust requirements.

• These agent-to-agent exchanges often directly mirror those that take place face-to-face in the physical world. However, they can also mirror how the same exchange would take place on the web today: i.e., via a website representing one party, or via websites or services designed to introduce multiple parties (such as social networks, dating sites, online communities).

• Once established, an SSI connection can also provide passwordless login to any SSI-enabled website or app, can send and receive credentials and proofs in either direction, and can last as long as both parties need it—it does not need to depend on any intermediaries to stay active.

• Entire multi-party workflows, such as applying for a job, buying a car, or one person selling a car to another, can be accomplished by putting together the same basic SSI building blocks.

What may not yet be clear is just how much value can be produced with this new paradigm for achieving digital trust. That is the subject of chapter 4, where we introduce the SSI Scorecard.

SSI Resources For more free content to learn about SSI, please go to IdentityBook.info and SSIMeet up.org/book.

Reference

1. Gisolfi, Dan. 2018. “Decentralized Identity: An Alternative to Password-Based Authentication.” IBM. https://www.ibm.com/blogs/blockchain/2018/10/decentralized-identity-an-alternative-to -password-based-authentication.