Darrell O’Donnell

We introduced digital wallets and agents in chapter 2 as two of the basic building blocks of self-sovereign identity (SSI). While the basic concepts are relatively straightforward, the details could easily fill an entire book. This chapter is based on Darrell O’Donnell’s continuously updated report on the state of digital wallets that he began writing in the winter of 2019. Digital wallet and agent technology has been advancing so fast that Darrell has been speaking globally about the evolving industry since then. Darrell is uniquely suited to write on this subject because he advises and works with many startups, large corporations, and governments that are down in the trenches of SSI, establishing the basic and advanced capabilities required. He is an entrepreneur, investor, and technologist implementing and supporting SSI, digital wallets, and agents.

If I look in my wallet, most of the stuff in there is nothing to do with payments. If Apple or Google want to replace my wallet, that means that they have to replace my driving licence, my loyalty cards, my rail discount pass, my travel insurance, my health insurance document, my blood donor card, my AA membership... well, you get the point... But in the long term, it’s much more valuable.

—Dave Birch, Forbes [1]

Digital wallets and agents are to SSI what browsers and servers are to the web: the basic tools we need to make the whole infrastructure work. While browsers and servers exchange web pages, digital wallets and agents exchange verifiable digital credentials (VCs). (Digital wallets and agents can also use the DIDComm protocol to exchange any other form of cryptographically verifiable data. See chapter 5.)

As simple as the concept of a digital wallet sounds, when you add up all the requirements for security, privacy, cryptography, functionality, portability, and usability, it becomes a real feat of engineering. Building a full-featured SSI wallet is a design and development effort similar in scope to building a full-featured browser. Since the space is evolving so fast, for a list of current SSI digital wallet projects, see the Wikipedia page on SSI.

In this chapter, we cover the following:

• What is a digital wallet, and what does it typically contain?

• What is a digital agent, and how does it typically work with a digital wallet?

• An example usage scenario.

• Design principles for digital wallets and agents.

• Basic anatomy of a digital wallet and agent.

• Standard features of end-user digital wallets and agents.

• Backup and recovery.

• Advanced features of wallets and agents.

• Enterprise wallets and agents.

• Special features for guardianship and delegation.

• The “wallet wars”—the coming battle between open source, open standard, and proprietary digital wallets and agents.

Note that one topic closely associated with digital wallets—key management—is deep enough that we cover it separately in the next chapter.

Topics we will not cover in this chapter, except for brief mentions, include the following:

• Cryptocurrency wallets

• Payments and value exchange

• Personal data stores (PDS) and secure data storage (SDS) (aka identity hubs and encrypted data vaults)

9.1 What is a digital wallet, and what does it typically contain?

We should say right up front that there is not yet a universally accepted definition of the term digital wallet. There are at least half a dozen definitions, depending on the particular segment of the SSI community you talk to. The one overarching theme everyone seems to agree on is this:

A digital wallet consists of software (and optionally hardware) that enables the wallet’s controller to generate, store, manage, and protect cryptographic keys, secrets, and other sensitive private data.

In other words, a digital wallet (and the digital agent used with it—see the next section) is the nexus of control for every individual, organization, and thing participating in SSI.

Interestingly, what falls under the heading of “other sensitive private data” that might be stored in a digital wallet is as varied as what people might choose to put in their physical wallets or purses. Some current or planned SSI digital wallet implementations include these:

• Decentralized identifiers (DIDs: peer DIDs, contextual DIDs, public DIDs for any of your relationships)

• Verifiable credentials for which you are the holder

• Digital copies (e.g., PDFs) of physical credentials such as passports, driver’s licenses, birth certificates, diplomas, and other credentials that have not yet been converted into verifiable credentials

• Business cards and other personal contact information

• Personal data of all kinds

• Resumes, CVs, and other biographical information

• Usernames, passwords, and other data typically maintained in a password manager

Again, this list does not include data related to cryptocurrencies, digital tokens, or other forms of value exchange, as those are currently the domains of more specialized cryptocurrency wallets. However, many believe that SSI wallets and cryptocurrency wallets are on a collision course and will become one and the same in the future. See chapter 17 for more.

9.2 What is a digital agent, and how does it typically work with a digital wallet?

In chapter 2, we compared physical wallets with digital wallets and used the analogy that a physical wallet doesn’t do anything by itself; rather, it is always a person—the owner—who puts credentials into the wallet and takes them out to show proof of the owner’s identity. With a digital wallet, the owner needs software to manage those interactions. This software module is known as a digital agent.

SSI community terminology around the term agent is still fuzzy. For example,

• Some SSI vendors do not differentiate between digital wallet and agent functionality and simply call their entire application a digital wallet or mobile wallet. In this case, you can consider the agent functionality built-into the wallet.

• Other SSI vendors take the opposite approach and consider their digital agent to be the primary offering. In this case, the wallet functionality is treated as a feature of the agent.

• To top it off, the term agent has myriad uses and meanings in the world of software and networking. For example, both web browsers and email clients are technically called user agents. Intelligent agents are another computer science category that can cover anything from a digital thermostat to an autonomous drone. Entire populations of agents can be combined into complex adaptive systems whose emergent behavior is more than the sum of the parts, as described in chapter 19.

For this chapter, we use the following definition:

A digital agent is to a digital wallet what an operating system is to a computer or smart-phone. It is the software that enables a person to take actions, perform communications, store information, and track usage of the digital wallet.

This means a digital agent typically performs the following functions on behalf of the person or organization in control (whom we call the controller):

• Request the generation of cryptographic key pairs and DIDs from the wallet.

• Initiate and negotiate DID-to-DID connections to form new relationships.

• Request the issuance of a verifiable credential, accept the issued credential, and store it in the wallet.

• Receive a request from a verifier for proof of one or more claims from a credential, ask the controller for consent to release the proof, calculate the required proof (including any necessary digital signature), and deliver the proof to the verifier.

• Accept notification messages received over a connection, apply the controller’s filtering rules, and, if necessary, notify the controller and process any resulting action.

• Send digitally signed messages from the controller to one or more of the controller’s connections.

• Apply digital signatures to documents or artifacts at the controller’s request.

9.3 An example scenario

To ground our discussion of the various functions of digital wallets and agents, let’s take a real-world scenario where we make frequent use of our physical wallets: a business trip. From start to finish, these are the times on a business trip when you usually need to share information from your physical wallet:

1. Making plane, car rental, and hotel reservations

2. Passing through airport security

3. Presenting your boarding pass for the plane

4. Car rental, hotel, and conference check-ins

5. Business card exchange

It’s easy to envision the all-digital version of this scenario if you see your agent as your surrogate, doing most of the work, and your digital wallet as a replacement for your physical wallet. Assuming that you have an agent and wallet installed on your smartphone, here are the digital versions of each step:

1. Making plane, car rental, and hotel reservations —At each website, you use your phone to scan a QR code. Your agent prompts you for permission to establish a private, peer-to-peer connection. (After associating this new connection with your existing website account, you should be able to “log in” to the website using your digital agent and wallet without any username or password.) When you are finished making your reservation, your agent prompts you to accept a digital credential for your reservation. When you click Yes, your agent stores the reservation credential directly in your digital wallet, ready for your trip.

2. Passing through airport security —You tap your phone on an NFC device, and your agent prompts you to share the required information from an acceptable government ID credential. You click Yes, the security agent verifies your picture, and you are good to go.

3. Presenting your boarding pass for the plane —Your phone connects with a Bluetooth Low Energy (BLE) device when you are three feet from the gate as you get in line to board the plane. Your digital agent (not the gate agent) prompts you to share your plane reservation credential. You click Yes. A facial recognition scanner compares your face with your plane reservation. If everything matches, the light turns green, and you board the plane.

4. Car rental, hotel, and conference check-ins —Each of these is essentially the same ceremony: you scan a QR code, are prompted by your agent to share the necessary credential proofs, click Yes, wait for the proofs to be verified and your biometrics (such as your picture) to be matched, and then are finished.

5. Business card exchange —When you meet someone at a conference with whom you want to exchange business cards, one of the two of you opens your digital wallet app and clicks the menu to display a QR code. The other one scans it. (This ceremony can also work via Bluetooth, NFC, and other edge networking protocols.) The two agents instantly negotiate a private DID-to-DID connection. Then each agent prompts its controller for the business card(s) to share over this new connection. Choose the card(s), and you’re finished. You both now have a direct personal connection—with no intermediary—that will last as long as you both want it. (We walk through this person-to-person connection scenario in greater detail in chapter 3.)

NOTE In the context of the COVID-19 crisis and potential similar future situations, 100% of the transactions just described can be touchless. The ability to carry on business as usual without direct physical contact becomes a real advantage of SSI.

9.4 Design principles for SSI digital wallets and agents

This new breed of digital wallets and agents designed for SSI is unlike any attempt at digital wallets before (and there have been many). The main reason is that to be compatible with the philosophy of SSI discussed throughout this book, SSI wallets and agents need to follow the design principles in this section.

9.4.1 Portable and Open-By-Default

As we explained in chapter 2, almost every smartphone today comes with a digital wallet built in. Although vendors like Apple and Google allow third parties to design credentials to be used with their wallets, they are still proprietary wallet APIs controlled by single vendors—and the credentials they contain are not portable to other digital wallets.

From an SSI perspective, that makes about as much sense as buying a physical wallet that came with rules restricting what you can and cannot put in the wallet. Of course, you would never tolerate that.

So the number-one design criteria for SSI-compatible digital wallets is that they must implement open standards for DIDs, cryptographic keys, verifiable credentials, and any other user-controlled contents. This enables the controller to enjoy true data portability: i.e., the ability at any point in time to move all of the contents of their wallet to a different wallet from a different vendor—or even to build their own.

This also means multiple digital wallets and agents from different vendors should be able to fully interoperate on behalf of the same controller—whether that controller is a person with multiple devices (e.g., smartphone, tablet, laptop) or an organization with different operating systems and applications from multiple vendors (not to mention different employees using different devices and operating systems).

While the requirement in some digital trust ecosystems to use only certified and accredited devices may limit portability (see more about that topic in chapter 11), these limitations will likely only apply to very high-assurance situations (e.g., approving large money transfers; signing legal documents for a corporation).

9.4.2 Consent-driven

A second core design principle is that, given the sensitive nature and value of a digital wallet’s contents, a digital agent should never take an action that has not been authorized by its controller. This doesn’t mean an agent must interrupt its controller for consent every single time any transaction is made. Agents can be designed to remember the policies and preferences of their controllers and automatically take certain actions with the controller’s consent. A common example, already widely implemented in banking, is auto-payment of recurring bills. The account owner sets up the rules, and the bank’s backend systems automatically pay certain bills every month.

Digital agents can do the same thing for many routine transactions. However, for anything that is not routine, such as forming a new relationship or performing a new type of transaction, the agent must request explicit consent from the controller. One of the SSI infrastructure’s best features is that digital agents and wallets can produce an auditable log of controller consent actions for both parties for every transaction. Thus in business-to-consumer (B2C) transactions, both the business and the consumer can have their own cryptographically verifiable event logs. This enables businesses to comply with data protection regulations such as General Data Protection Regulation (GDPR) while enabling consumers to track down when and where they shared sensitive personal data (and thus to more easily monitor, update, or delete it as desired).

9.4.3 Privacy by design

The previous design principles already address some of the principles of privacy by design as originally defined by Ann Cavoukian during her tenure as Ontario information and privacy commissioner (and adopted by the International Assembly of Privacy Commissioners and Data Protection Authorities in 2010). Given that a digital wallet and its accompanying agent should be among the most trusted tools we have for navigating the wild and woolly World Wide Web, it is highly recommended that implementers follow all seven principles:

1. Proactive, not reactive; preventive, not remedial

2. Privacy as the default setting

3. Privacy embedded into the design

4. Full functionality—positive-sum, not zero-sum

5. End-to-end security—full life-cycle protection

6. Visibility and transparency—keep it open

7. Respect for user privacy—keep it user-centric

As we discussed in chapter 5, the overall architecture of SSI makes it possible to implement privacy by design on a scale that has not been possible before. Specifically, SSI can offer the following:

1. Cryptographically protected private storage —Although some of us use password managers today, many others do not have any place to safely store and guard the personal data they share on the web. That is why merely having (or stealing) access to that data can be used to impersonate someone for the purpose of identity theft. SSI digital wallets finally give us a standard place to safely lock up private personal data so it is used only with our consent.

2. Privacy-protected connections —Digital agents can form private peer-to-peer connections by exchanging peer DIDs and DID documents so we do not have to rely on intermediaries to maintain and monitor our communications relationships.

3. End-to-end encryption —Messages and data exchanges can be encrypted from wallet to wallet (or DID to DID) so they can be viewed only by the authorized parties.

4. Watermarked personal data —Data shared using verifiable credentials has cryptographically verifiable proof of the associated consent. This turns the tables on data brokers and others so that anyone using unmarked personal data—data without the associated consent—will have to prove they have a legitimate reason.

5. Shared governance frameworks —Today’s privacy policies exist primarily to protect the rights of businesses to use personal data as they define it. Because the power relationship is so asymmetric, consumers are essentially unable to say no if they need the product or service the business provides. SSI governance frameworks, discussed in detail in chapter 11, provide a new tool to establish much broader privacy and data protection norms—and, consequently, bring much more public and regulatory pressure to bear on businesses to “do the right thing” with their privacy and data protection practices.

9.4.4 Security by design

If there is one thing every digital wallet must do very well, it is to securely store and safeguard its contents. Those contents are the keys to the (digital) kingdom. If an attacker can break into or steal the contents of a digital wallet, they can do very serious damage.

Fortunately, we can make this a very uneven playing field—tilted in favor of the good guys—by using the following security-by-design features of SSI architecture:

• Secure hardware —Designers and developers of digital wallets can take advantage of specialized hardware components (secure enclaves in smartphones, trusted execution environments in computers, hardware security modules in servers) designed explicitly for secure storage and protection of digital keys and other sensitive data.

• SSI decentralization by design —As a rule, digital wallets will be spread out all over the edges of the network, where they are hardest to attack. Furthermore, breaking into a single digital wallet will net the attacker only a limited set of keys and secrets with which to compromise a single controller—not a giant honeypot of personal data that, once penetrated, can be used to impersonate millions of people.

• Private DID-to-DID connections —These are individually authorized, verified as authentic using an exchange of digital credentials, and end-to-end message-encrypted by default. This means attackers have far fewer entry points with which to try to launch an attack (especially compared to the wide-open email addresses used for all manner of social engineering attacks today).

• Using well-designed governance frameworks —SSI can use well-designed governance frameworks to propagate and enforce best-of-breed security practices across all members of a digital trust ecosystem—vendors, issuers, holders, verifiers, auditors, and so on.

• Digital agents as their own monitors —Every digital agent can serve as its own monitor of local security-related activities and watch for possible signs of a breach, applying the security principle of “many eyes” to detect attacks and coordinate responses across entire digital trust ecosystems.

9.5 Basic anatomy of an SSI digital wallet and agent

Figure 9.1 shows the conceptual architecture of a typical SSI wallet and agent. The top box shows the primary agent functions, and the bottom box shows the primary wallet functions called by the agent.

Figure 9.1 Conceptual architecture of a typical SSI digital wallet and agent

Although specific wallet/agent implementations may differ in how they divide up these functions, broadly speaking, they will cover the areas in Table 9.1.

Table 9.1 Core functions of SSI digital wallets and agents

Component	Function
Agent	Messaging—In some ways, an agent functions like a specialized email or chat application: it sends and receives data, structured messages, and push notifications on behalf of the controller. This can be any combination of tightly defined protocol messages (such as those used for peer DID or verifiable credential exchange), structured messages defined by either party, and general-purpose secure messages.
	Routing—Some agents, particularly those representing enterprises or agencies, serve as intermediaries for routing other agent-to-agent messages using protocols like DIDComm, designed for multi-agent routing. DIDComm originated in the Hyperledger Aries project and is being standardized by the DIDComm Working Group at the Decentralized Identity Foundation (https://identity.foundation/working-groups/did-comm.html). It has explicit support for the “Russian doll” nesting of encrypted messages to support privacy-respecting multi-agent routing.
	Backup and recovery—Given the value and sensitivity of the data stored in a digital wallet, in almost every case, the wallet must support robust backup and recovery options in case of loss, corruption, or hacking of the wallet/agent software and/or hardware. See section 9.7.
	Secure storage—This component of an agent calls the wallet’s services, typically via a secure API provided by the wallet.
Wallet	Key management system—The heart of every digital wallet is how it handles the generation, rotation, revocation, storage, signing, and protection of cryptographic keys and associated secrets such as the link secrets used in zero-knowledge proofs. You can read more about this in chapter 10.
	Encrypted storage—The other primary wallet function is the protected storage of the keys, secrets, and other private data that the controller elects to store in the wallet. Depending on the size and type of wallet, this may take many forms, e.g., secure enclaves on mobile phones, secure storage governed by trusted execution environments (TEEs), or hardware security modules (HSMs) on servers and cloud-hosted wallets.

For another perspective on what should be standard in an SSI digital wallet, see the draft Universal Wallet specification submitted to the W3C Credentials Community Group in August 2020 by Orie Steele of Transmute (https://w3c-ccg.github.io/univer sal-wallet-interop-spec).

9.6 Standard features of end-user digital wallets and agents

In addition to the basic features and functions covered in table 9.1, this section lists other features commonly provided by commercial-grade digital wallets intended for personal use.

9.6.1 Notifications and user experience

Whether the application is called a digital wallet or a digital agent or both, there is universal agreement that it is the critical component in managing the user experience (UX) of SSI. This is where the rubber meets the road as to whether self-sovereign identity actually looks and feels “self-sovereign.” For example, does the end user

• Feel fully informed about what is happening with their credentials and the sensitive personal data those credentials may contain (identity data, health data, financial data, family data, travel data)?

• Trust the providers of the wallet and agent software and hardware?

• Trust the credential issuers?

• Trust the credential verifiers?

• Trust the governance frameworks and trust marks under which providers, issuers, and/or verifiers are operating?

• Trust the peer-to-peer connections they are making?

• Feel fully in control of the whole experience, such that the user’s confidence in their use of the internet, their digital identity, and the privacy, security, and protection of their personal data is significantly (or dramatically) better?

Of course, part of this is also the end user’s feeling of satisfaction with the behavior of the wallet and agent application, particularly with regard to the following:

• How easy and intuitive is it to use?

• How carefully does it balance between security, privacy, and ease of use?

• How often and accurately does it notify the user—and how appropriate are the interrupts when it needs to “steal the user’s attention”?

This last question is particularly important when it comes to a highly secure application like a digital wallet. Mobile and desktop operating systems such as iOS, Android, macOS, and Microsoft Windows already have sophisticated notification systems that notify the user only when it’s necessary or relevant. (Microsoft learned the hard way when it added so many new security notifications in Windows 10 that users either ignored them or turned off all notifications.) But even those can be challenging to configure or tune. If a digital wallet and agent app is to earn the user’s respect and trust, it must be very sensitive to providing only notifications the user must see (for legal reasons, like GDPR), should see (for security reasons, such as authentication), and/or wants to see (for an exchange of value, or to better control their personal information).

9.6.2 Connecting: Establishing new digital trust relationships

SSI architecture pairs a digital agent with a digital wallet because the cryptographic keys, secrets, and credentials stored in the wallet don’t do anything by themselves. Their entire purpose is for building and maintaining digital trust relationships on behalf of their controller.

One of the most frequent actions the controller will take is scanning a QR code, tapping a Near-Field Communication (NFC) or BLE device, clicking a link, or otherwise activating their agent to form a new DID-to-DID connection with a person, an organization, or a thing. For example, in our scenario of an all-digital business trip, each step in the journey involved creating a new connection (if one did not already exist) with an airline, car rental company, hotel, conference registrar, and so on.

Fortunately a digital agent makes this a simple, standard action requiring no knowledge of cryptography, key management, or any of the underlying complexity—just scan a QR code or click a link, approve the new connection, and decide what credentials to exchange in that particular interaction. Both parties to the connection enjoy these benefits:

• Your agent and wallet will automatically remember the connection. It’s like having an assistant automatically add each new person you meet to your address book.

• The connection will last as long as you need it. There is no reason for it to break because the other party moves, changes address, or somehow loses touch. SSI connections only need to end when one or both parties no longer want them.

• The connection has no intermediary. There is no social network, email provider, or telco between the connected parties.

• All messages are encrypted end-to-end. This new communication channel is completely secure and private to the connected parties.

• You can use the connection for anything you want. There are no third-party terms of service for an SSI connection. It belongs entirely to the connected parties, who can use it for any application they want.

9.6.3 Receiving, offering, and presenting digital credentials

Once a connection is established, the typical next step is for the parties to exchange credentials in one or both directions—either to issue new credentials (the left leg of the trust triangle in figure 9.2) or to verify issued credentials (the right leg of figure 9.2).

Figure 9.2 The verifiable credential trust triangle

Both processes are carefully orchestrated dances between the agents for the two parties—and these dances can vary depending on the credential format being used. In general, the credential-issuance process proceeds along these lines:

1. The issuer requests whatever authentication is necessary for the holder to qualify for a new credential.

2. Once authenticated, either the holder requests a new credential or the issuer offers a new credential.

3. Either way, the issuer agrees to issue the credential, and the holder consents to accept it.

4. The issuer’s agent and the holder’s agent follow the specific protocol steps for issuing a credential in the desired format.

5. At the conclusion of the protocol, the issued credential is downloaded into the holder’s wallet.

The credential-verification process proceeds with these general steps:

1. The holder requests some interaction with a verifier that requires verification (such as requesting access to a non-public web page).

2. The verifier presents a proof request to the holder (such as displaying a QR code that the holder can scan with a smartphone).

3. The holder’s agent processes the proof request and determines whether the holder’s wallet contains the credentials and/or claims necessary to satisfy it. If so, it prompts the holder to share a proof.

4. The holder consents to share the proof.

5. The holder’s agent prepares the proof presentation and sends it to the verifier’s agent.

6. The verifier’s agent uses the issuer’s DID in the proof response together with the credential definition (and any other information needed from the associated verifiable data registry) to verify the proof.

7. If the proof verifies, the holder is granted access.

One significant variation in this process is when the credential uses zero-knowledge proof (ZKP) cryptography. In this case, the holder’s agent and wallet can support sophisticated selective disclosure features (see https://www.privacypatterns.org/patterns/Support-Selective-Disclosure). This means the verifier sees only the exact information required by the proof request. For example, if the verifier only needs to know the holder is over 21, the holder can prove that fact without revealing the holder’s actual age or birthdate.

Support for ZKP-based verifiable credentials, which are explicitly supported in the W3C Verifiable Credentials Data Model standard, is one of the key differentiating features of SSI agents and wallets. The earliest work on this feature started in the Hyperledger Indy and Aries open source projects in 2018, but it is now spreading to other SSI digital wallet and VC projects.

9.6.4 Revoking and expiring digital credentials

Once a physical credential has been issued to a person and stored in their wallet, the only practical way to revoke it is to give it an expiration date. If the credential needs to be revoked before the expiration date—such as a driver’s license being revoked due to traffic offenses or a passport being revoked due to a change in citizenship—the only way a verifier can check the revocation status is to contact the issuer.

With digital credentials, agents, and wallets, we can do better. In order of increasing preference:

• Verifiers can check with issuers via an online API. This is the least desirable option because it still requires verifiers to integrate with issuers, and it requires issuers to host a high-availability evocation API.

• Issuers can maintain a revocation registry using a Layer 1 verifiable data registry (VDR) such as a blockchain or distributed ledger. This solves the problem of verifiers needing to integrate with issuers—a verifier only needs to integrate with the VDR—and also of issuers needing to host their own revocation API. However, a conventional revocation registry can leak privacy information about revoked credentials.

• The most privacy-preserving solution is to maintain a revocation registry on a VDR that uses ZKP cryptography. This enables verifiers to check on the revocation status of a credential in near-real time but only when a holder presents a proof. Otherwise, the revocation registry does not reveal any information about what credentials have been revoked.

Again, all the complexity (and work) of updating and verifying a credential’s revocation status is handled automatically by agents for the issuer, holder, and verifier.

9.6.5 Authenticating: Logging you in

Usernames and passwords are the banes of our online existence. Some of us maintain long lists in spreadsheets or word processors. Others use password managers like Apple Keychain, 1Password, LastPass, and Dashlane. Regardless of the solution, the problem is a universal headache—and with over 3 billion people online, that’s a pretty big headache. It is also one of the weakest points of our cybersecurity infrastructure.

As chapter 4 explained, auto-authentication is one of the headline benefits of SSI. From what we’ve covered in this chapter so far, it should be easy to understand how your agent and wallet can finally relieve you of the burden of usernames and passwords—essentially eliminating the need for you to “log in” at all.

They simply do the job for you. The peer DID your agent negotiates when it first creates a new connection becomes your “username,” and your digital signature on a message sent over the connection becomes your “password.”

note Cryptographically, your digital signature, produced using the private key associated with your peer DID, is much stronger than any password.

This is already considered multi-factor authentication (MFA) because it requires both your digital wallet and at least a PIN or passcode to unlock it. A verifier that needs an even higher level of assurance that it’s really you can request the following:

• A biometric (e.g., fingerprint, facial scan) to open your digital wallet

• A proof of one or more verifiable credentials in your wallet

• A liveness check (such as recording a short video) to prove that you—the person holding the wallet—are the holder to whom the credentials were issued

All of these are well-known MFA techniques that have been incorporated into federated identity standards like OpenID Connect and Fast IDentification Online (FIDO). SSI wallets and agents standardize and automate MFA in much the same way smartphones have automated the process of remembering and dialing phone numbers. As SSI adoption spreads, the process of manually entering a username and password to log in to a website will start to seem as antiquated as dialing a rotary telephone (digit ... by ... digit ... by ... digit).

9.6.6 Applying digital signatures

Just as your agent and wallet can digitally sign a message to authenticate you, they can sign almost any other digital object requiring your signature. The basic steps are as follows:

1. You establish a connection with the party requesting the signature (the verifier).

2. The verifier uses the connection to send you the object requiring your signature (e.g., a structured message, a PDF document, a JSON file). (Depending on the digital object, you can sign it directly or sign a hash of the object after your agent and wallet verify the hash. See chapter 6.)

3. Your agent prompts you to approve the signature request.

4. Your agent calls your digital wallet to generate the signature based on the appropriate DID and private key.

5. Your wallet returns the signature to the agent.

6. Your agent returns the signature to the verifier.

Note that this digital signature process is an order of magnitude stronger than most “electronic signature” services such as DocuSign, HelloSign, and PandaDoc. As a rule, those services do not apply cryptographically generated digital signatures; rather, they apply digital facsimiles of handwritten signatures. The latter are legally accepted in most jurisdictions, but they are not cryptographically bound to the underlying digital document.

9.7 Backup and recovery

At this point, it should be clear that a well-used digital wallet will rapidly become as valuable—if not more valuable—than a physical wallet. So what if you lose it or it is stolen, hacked, or corrupted?

Ironically, a well designed and engineered digital wallet should be safer and better protected from loss than a physical wallet—but only if the owner takes the necessary recovery preparation steps. This section explains why.

9.7.1 Automatic encrypted backup

Any commercial-grade SSI wallet should come with an automatic encrypted backup feature. After an initial setup step to establish your recovery keys, your agent will automatically and continuously maintain an encrypted backup copy of your wallet in the location of your choice. Usually, that means in the cloud—either on a generic cloud-based storage service like Dropbox or Google Drive or on a specialized encrypted backup service from your wallet/agent vendor.

note Unlike many crypto wallets, an SSI wallet requires a backup file and recovery keys. The backup file is needed because the wallet may be the only place where certain data exists.

This way, if anything happens to your wallet—e.g., your device is lost, stolen, corrupted, or broken—you can recover the contents of your digital wallet right up to the most recent actions you took with it. Recovery is typically performed using one of the options discussed next.

9.7.2 Offline recovery

The first option is to simply store a copy of your recovery keys in a safe location offline (cold storage) where you can find them when you need to recover (figure 9.3). This is not as easy as it sounds. To begin with, you have to hide your recovery keys in a safe place where only you or your trusted delegates can access them (otherwise, they could be used to steal your digital wallet without your permission).

Figure 9.3 Typical offline recovery techniques: QR codes and hardware cold-storage devices

Second, you need to be able to locate your recovery keys many years or even decades after you first store them. (Even safe deposit boxes in banks can be difficult to access after long periods of inactivity.)

Third, you need to make sure your recovery keys stay fully intact. For example, if you store them on a cold-storage device, such as a USB key, it better not suffer a hardware failure. If you store them on paper, such as a printed QR code or written passphrase, you must guard against the print fading over time or being incinerated in a fire. This is why some experts recommend etching recovery keys in titanium or another fireproof metal. (The Blockchain Commons Smart Custody Project has much more information about key backup and recovery options: https://www.smartcustody.com.)

Keep in mind that if your recovery key is lost or corrupted, there is no other way to recover your digital wallet. With SSI, there is no “password reset service” you can call and no higher authority to appeal too. If there were, it would not be self-sovereign—someone else would ultimately be in control.

9.7.3 Social recovery

A second option is called social recovery because it relies on one or more of your trusted connections to assist you in recovery. In this approach, rather than printing or saving your recovery key offline (or in addition to doing that), your agent and wallet use a cryptographic technique called key sharding to break your recovery key into several fragments. At least M of N of these fragments (for example, two out of three) must be brought back together to reproduce the original recovery key. Your agent then encrypts and shares a shard over the connection you have with each of your chosen trustees—the people or institutions you trust to safeguard the shard and return it to you (and only you) if you ever need to recover. This is illustrated in figure 9.4.

Figure 9.4 Sharing a sharded recovery key using social recovery

The primary advantages of social recovery are as follows:

• It doesn’t require storing or remembering the location of an offline recovery key.

• The recovery process can be performed entirely online, provided you can contact a sufficient number of your trustees (and convince them it is really you).

• You can periodically adjust your trustees so they represent the connections you trust the most at any particular time.

• Your agent can periodically remind you of your trustees (and them of you) to make it easier to recover if you need to.

The downsides of social recovery are these:

• A sufficient number of your trustees must be available to decrypt and share back their shards when you need to recover.

• Your trustees are potentially subject to a social engineering attack by a determined adversary who wants to trick them into sharing enough shards to assemble your recovery key and steal your encrypted backup.

9.7.4 Multi-device recovery

A third option for recovery—and usually the easiest—is available if you have a digital wallet installed on more than one device. This option is essentially self-recovery because it works just like social recovery but is performed with your own family of devices. If one of your devices becomes lost, damaged, or corrupted, you use your other devices to share back shards of your recovery key to a new device. See section 9.8.1.

9.8 Advanced features of wallets and agents

This section covers more sophisticated capabilities that we expect to see on the market within a few years of this book’s publication.

9.8.1 Multiple-device support and wallet synchronization

Multi-device support is a standard feature of many modern apps (e.g., Slack, Facebook, iMessage) and even operating systems (Apple Keychain, iCloud) because they want to provide a consistent user experience across all your devices. Generally, they do this by synchronizing each instance of the app via a cloud service.

Like these apps, your digital wallet will be immensely more useful if it can operate seamlessly across all your devices. However, synchronizing it is much more challenging due to the security requirements. Complete synchronization is often impossible because private keys simply cannot be copied out of secure enclaves or other hardware security modules, for good security reasons. And some high-assurance credentials may require binding the wallet to a particular device, requiring the credential to be re-issued to move it to a different wallet.

Open source projects and wallet/agent vendors are currently working on cross-wallet synchronization protocols that will address these challenges—while at the same time enabling digital wallet portability and interoperability. Early architectural work in this area began with the Decentralized Key Management System (DKMS) project contributed to Hyperledger Indy (http://mng.bz/5jP8) and continues in the DIDComm Working Group at the Decentralized Identity Foundation (https://identity.foundation /working-groups/did-comm.html).

9.8.2 Offline operations

Today, if you were driving too fast in the remote reaches of Canada and a Royal Canadian Mounted Police (RCMP) officer pulled you over and asked to see your driver’s license, you would simply reach into your wallet and hand it over. Internet connectivity would not be a factor.

But if all you had was your digital wallet—and the only way you could show your driver’s license was if you had an internet connection—that would be a problem. If you are in a no-coverage area—or if your data plan doesn’t work in Canada—how can the officer verify your digital driver’s license?

This is not a hypothetical situation. Governmental agencies in multiple countries and several U.S. states have already published requests for proposals (RFPs) for digital driver’s licenses that require that they be verifiable without an internet connection. Many edge networking protocols such as Bluetooth and NFC enable this, so the only real obstacle is standardization and interoperability testing.

9.8.3 Verifying the verifier

Any new technology that offers significant new benefits also entails new risks. As SSI gains traction in the market, one risk that regulatory authorities like the European Commission are concerned about is coercion: verifiers abusing the power of SSI digital wallets and agents to make information quickly and easily available by coercing holders to share certain credentials or claims as a requirement of receiving service.

The Request for Comments (RFC) for the Trust over IP stack stated the risk of coercion this way:

The concept of “self-sovereign” identity presumes that parties are free to enter a trans-action, to share personal and confidential information, and to walk away when requests by the other party are deemed unreasonable or even unlawful. In practice, this is often not the case... A point in case are the infamous cookie walls, where a visitor of a website get the choice between “accept all cookies or go into the maze-without-exit.”

note See https://github.com/hyperledger/aries-rfcs/tree/master/con cepts/0289-toip-stack#countermeasures-against-coercion. The section on anti-coercion was contributed by Oskar van Deventer of TNO in the Netherlands.

The RFC goes on to explain the basic strategy for protecting against such coercion:

Governance frameworks may be certified to implement one or more potential counter-measures against different types of coercion. In case of a machine readable governance framework, some such countermeasures may be automatically enforced, safeguarding the user from being coerced into action against their own interest.

The number-one countermeasure recommended by this RFC has become known as verifying the verifier. It is a governance framework policy that requires a verifier to be authorized under the governance framework to make a particular proof request. The holder’s agent can verify this authorization—typically by checking that the verifier’s public DID is included in a verifiable data registry maintained by governance authority—before the agent even asks the holder for consent to share the proof. If the “verifying the verifier” check fails, the agent can not only refuse to proceed but can warn the holder of a possible scam—and even automatically report a possible violation to the governance authority.

This technique is not entirely new. Similar protections exist on global credit card networks today: for example, only an authorized Mastercard merchant network can request payment using a Mastercard. But with SSI, this kind of protection can be extended to any type of verifiable data exchange. And it can directly support data-protection regulations in various jurisdictions.

9.8.4 Compliance and monitoring

Verifying the verifier is just one type of regulatory or governance compliance for which an agent can monitor. As a trusted digital assistant (assuming the controller does trust the agent), an agent can watch for other behaviors, conditions, and actions:

• Applicable governance frameworks —Is a credential being issued under a governance framework that the controller trusts? If it is new, can the agent verify the bona fides of the governance authority? Who else is using or endorses the governance framework?

• Sensitive data —Is a verifier asking for especially sensitive data, and if so, why? See section 9.8.6 for how agents can recognize such requests.

• Receipt tracking —Agents can automatically categorize, store, and monitor your transaction receipts to help you analyze your activities. Personal finance software like Quicken and Mint already do this. So do personal health monitors like Apple Health and CommonHealth (https://www.commonhealth.org). Enterprise agents can monitor to be sure a transaction taken by an employee or contractor falls within the policies applicable to their role, e.g., buying authority, purchase categories, and spending limits.

Agents and wallets can also maintain cryptographically verifiable audit logs to enable forensic analysis if issues or problems arise. In some cases, particularly in an enterprise context, an agent may maintain a connection with and send regular reporting transactions to an independent auditing agent—one that may be hosted directly by a regulatory authority.

9.8.5 Secure data storage (vault) support

Just as your real-world wallet (or your pocket or purse) has a physical limit on how much it can carry, digital wallets are designed to store and protect a relatively limited amount of sensitive data. They are not generally designed to store your entire lifetime of financial records, tax records, health records (X-rays, CAT scans), educational records, portfolios, journals, files, and so on.

But you should have the capability to store any and all of these records under digital lock and key just as you would keep such documents safely in a fireproof file cabinet, home safe, or safe deposit box at a bank. Such a secure data store (SDS) has many names in the SSI community, including these:

• Personal data store (PDS)

• Personal cloud

• Hub (or identity hub)

• Vault (or encrypted data vault)

Regardless of the name, these all refer to the same basic design: electronic file storage (typically in the cloud) accessible only to the controller because the contents are encrypted with private keys from the controller’s digital wallet. The Secure Data Storage Working Group is developing standards and open source implementations for interoperable SDSs at the Decentralized Identity Foundation (https://identity .foundation/working-groups/secure-data-storage.html).

9.8.6 Schemas and overlays

The credentials stored in a digital wallet are based on underlying schemas that define the semantics and data type for each claim (attribute) in the credential. However, data semantics can be extremely rich and complex. Take just one dimension: the name of a claim. What language is it in? Can you describe the name in different languages? How do you add that description without making the basic schema definition very complex?

The answer is an architecture called schema overlays. As shown in figure 9.5, schema overlays are descriptions of a base schema that can add rich descriptive and contextual metadata without complicating the base schema.

Figure 9.5 Different producers and consumers of data can develop multiple schema overlays to provide rich metadata describing a single set of data.

The Inputs and Semantics Working Group is standardizing this overlay-capture architecture (OCA) at the Trust over IP Foundation (https://wiki.trustoverip.org/display/HOME/Inputs+and+Semantics+Working+Group). Digital wallets and agents that support schema overlays will make it easier for issuers, holders, and verifiers to identify, describe, and manage the credentials and claims they need. To cite an example from earlier in this chapter, a regulatory agency or an industry watchdog organization can publish a schema overlay describing the degree of privacy sensitivity of the data contained in specific credentials. Agents and wallets can use this overlay to warn verifiers about requesting and holders about sharing such highly privacy-sensitive data.

9.8.7 Emergencies

Government agencies and medical authorities publish guidelines about what information people should make easily available in their physical wallets in case of a medical emergency such as an accident, a heart attack, or an allergic reaction. The same applies to our digital wallets—if not even more so, for these reasons:

• If first responders can access emergency information in a digital wallet, it will make such data easier and faster to obtain.

• The information available can be much richer and more current than the data typically available in a physical wallet.

• The digital wallet can be configured to enable first responders to access other medical records for the holder that may be even more helpful.

• The digital wallet can allow first responders to quickly reach emergency contacts while still respecting their privacy.

For all these reasons, proprietary smartphone wallets such as Apple Wallet already support an emergency mode. For example, the author of this chapter provides information about a peanut allergy that anyone can use if they have access to his phone.

However, the information is very limited, and there is no restriction on who can access the device. By contrast, if a bona fide first responder can prove that fact (e.g., using a standard First Responder credential that the agent can verify), the agent can release much more information.

9.8.8 Insurance

Where there is risk, there is insurance. With digital wallets, agents, and credentials, there are these risks:

• The vendor of the wallet or agent software is negligent or malicious.

• The issuer of a digital credential makes an error, or their system gets hacked.

• A holder of a digital wallet has it hacked or stolen, and as a result, crimes are committed, or their credit score is ruined.

All three of these risks can be mitigated with different forms of insurance:

• Wallet and agent software vendors can be insured against product liabilities.

• Issuers can insure against mistakes in issued credentials or compromises in the issuer’s systems.

• Holders can insure against theft or loss of their digital wallet and the attendant damages.

Of course, the application for and issuance of an insurance policy for these types of coverage can be handled via—what else?—digital credentials. Having a cryptographically verifiable audit history of purchases by an insured party—such as a homeowner or business owner—can be extremely helpful in the unhappy situation of needing to file a claim due to loss from fire, theft, natural disaster, and so on.

9.9 Enterprise wallets

While the term wallet makes us think primarily about personal use, every entity participating in SSI needs a digital wallet. Even though organizations are run by people, jurisprudence requires that their legal identity (and thus their digital identity) must be separate from an individual. Even a sole proprietorship (a business operated by a single individual) is legally separate from the proprietor’s personal identity.

So every organization, no matter what the size, should have its own separate enterprise wallet. While enterprise wallets need all the standard features we have discussed, they also require the special features covered in this section.

9.9.1 Delegation (rights, roles, permissions)

In the context of SSI, delegation refers to one identity controller giving permission to another to perform certain actions on the first controller’s behalf. For example, an elderly parent might delegate to an adult child the authority to manage the parent’s bank account. With verifiable credentials, this is accomplished using a delegation credential. See section 9.10 for more.

While individuals may or may not need delegation for their personal agents and wallets, organizations have no choice. Enterprise wallets must be able to delegate authority for specific transactions to specific individuals acting in specific roles within the organization. These types of functions are often managed by directory systems and identity and access management (IAM) systems within many enterprises, adapted to work with SSI and digital credentials.

Besides the other advantages of SSI, the use of digital credentials for delegation will make it easier to orchestrate and digitally execute legally binding transactions across companies and borders. Some verifiable credential ecosystems are being developed explicitly to support this capability. The Global Legal Entity Identifier Foundation (GLEIF, https://www.gleif.org) is developing the vLEI, a verifiable credential version of the Legal Entity Identifier (LEI); see https://www.gleif.org/en/newsroom/blog/advancing-a-global-standard-in-digital-trust-with-the-trust-over-ip-foundation).

Organizations of any kind can be issued a digital LEI to verify their legal status. An organization can issue delegation credentials to its employees, directors, and contractors so they can provide proof of the specific roles in which they are authorized to act and digitally sign documents on behalf of the organization in a specific capacity.

9.9.2 Scale

While millions or billions of personal wallets and agents may be active at the same time, each is running on its own computing device at the edge of the network, so questions of throughput and scale are no different from those that the internet and cloud computing face today. However, enterprise wallets and agents are a different question. Here, instead of a single person performing authentication or exchanging credentials, you may have hundreds of thousands of employees actively authenticating or presenting enterprise credentials at the same time. So the underlying wallets, agents, and agencies need to function at that kind of scale. See chapter 10, especially section 10.8, for more on this topic.

9.9.3 Specialized wallets and agents

Individuals are likely served by a single wallet and agent per device, even though the agent may apply specialized behaviors for specific types of connections or credential exchanges. But enterprises may require specialized wallets and agents optimized for specific groups of tasks. For example:

• Accounting and Finance —Management of purchasing, invoicing, receipts, and expense tracking will likely create its own mini-industry of specialized agents. For example, every employee’s agent will probably have a connection to a Corporate Expense agent for automated expense tracking, reporting, and reimbursement.

• Operations —As covered in chapter 4, SSI will be a boon to business process automation. Many business processes can be orchestrated and automated by connecting employee and contractor agents to Business Process agents that apply the necessary business logic and help manage costly exceptions.

• Compliance —Recording and monitoring transactions for compliance with regulatory requirements can be simplified, and some cases can be automated, using Auditing and Reporting agents.

• News —Organizations thrive when different parts of the organization can share relevant and trusted information more quickly. As wallets and agents evolve, key events in which they participate (e.g., “contract signed,” “purchase order received”) can be shared instantly with looser integration than traditional systems integration requires.

9.9.4 Credential revocation

One of the classic challenges of IAM systems is managing hundreds of permissions across thousands of systems for millions of employees—and then updating them quickly when an employee’s or contractor’s status changes. With SSI, this complexity can be significantly reduced. The enterprise can issue revocable verifiable credentials, and every system or application can rely on them as a verifier. When an employee’s or contractor’s status changes, the relevant credentials can be revoked in near-real time without needing to know anything about what verifiers are relying on them.

9.9.5 Special security considerations

If personal wallets contain the keys to an individual’s kingdom, imagine the potential damage if an enterprise wallet suffers a major breach of security. Corporate assets worth millions or billions of dollars could be at stake—not to mention corporate reputation.

The good news is that, like a bank vault, an enterprise wallet is built from the ground up to support the levels of security necessary to protect such valuable assets:

• Multi-signature authorization policies —Depending on the level of sensitivity of a particular transaction, it may require multiple digital signatures from different employees, officers, or directors.

• Trust assurance frameworks —Most enterprises will operate enterprise wallets and agents under the provisions of one or more governance frameworks. These will commonly include a trust assurance framework that will require many industry-standard security practices, such as ISO 27001 certification (https://www.iso .org/isoiec-27001-information-security.html), together with period testing and recertification.

• Penetration testing —Rather than wait for problems to surface, enterprises can pay white-hat professionals to find and fix vulnerabilities.

• Automated monitoring and self-auditing —Enterprise agents can use their own sophisticated monitoring and self-inspection tools that employ artificial intelligence (AI) and machine learning to detect anomalies and predict problems.

• Device certification —Some enterprise use cases will support only certain devices or digital wallets that have been certified to meet specific security/privacy standards or governance frameworks, particularly for high-assurance use cases.

9.10 Guardianship and delegation

As we said at the beginning of this chapter, a digital wallet is the nexus of control for every participant in the SSI infrastructure. As powerful as this tool is, it limits the direct use of SSI to individuals who have digital access and the legal capacity to use the technology. For SSI to work for everyone, it must work for individuals who do not have digital access or do not have the appropriate physical, mental, or economic capacity to use a digital wallet and agent. These individuals require another person or organization to serve as their digital guardian.

Digital guardianship is first and foremost a legal and regulatory construct, so it is covered in more detail in chapter 11. However, we cover two technical aspects of digital guardianship in this section.

9.10.1 Guardian wallets

For most intents and purposes, a digital wallet under guardianship is functionally identical to a conventional SSI digital wallet. The difference is that the wallet’s controller is the guardian, not the individual who is the subject of the credentials in the wallet, who is called the dependent. When the guardian requests credentials on behalf of the dependent, or when the credentials are presented to a verifier on behalf of the dependent, it is the guardian who is asserting the dependent’s rights to self-sovereign identity.

There are countless cases where this pattern is needed: parents acting on behalf of babies or young children; adult children acting on behalf of aging parents; guardians acting on behalf of patients suffering from dementia or other physical or mental ailments; NGOs acting on behalf of refugees, homeless, or displaced populations; and so on.

The following distinguish guardian wallets:

• They are typically hosted in the cloud. This makes it easier for guardian delegates to access them using guardian credentials (see the next section). A service specializing in hosting guardian wallets is called a guardian agency.

• They use biometrics to authenticate the presence of the dependent. This is a safeguard against abuse that also provides a strong binding of the wallet and its contents to a specific human being. However, it is of paramount importance that any such biometrics be stored and managed following privacy-by-design principles that prevent the biometric from being stolen or weaponized against the dependent.

• They are typically controlled using guardian credentials (see the next section). This allows specifically authorized guardian delegates, such as members of a family or employees of an NGO, to take actions on behalf of a dependent but only after strongly authenticating themselves using their own SSI wallet and agent.

• They usually operate under strict governance frameworks that include special security, privacy, portability, and auditing requirements to prevent impersonation and abuse.

Ironically, a well-designed guardian wallet shares many features in common with an enterprise wallet because the set of directors, employees, or partners who control the enterprise wallet are essentially acting as “guardian delegates,” just in a different legal capacity than an actual guardian.

9.10.2 Guardian delegates and guardian credentials

Guardians can be either individuals, such as parents for their children, or organizations, such as NGOs helping refugees or homeless persons. In the case of individuals, the guardian may or may not have a guardianship credential—a credential issued by a legal authority, such as a government agency that officially appoints the individual as a guardian. In the case of an organization, a guardianship credential is often a prerequisite for digital guardianship because it is required under a guardianship governance framework of some kind (see section 11.7 and the white paper “On Guardianship and Self-Sovereign Identity,” Sovrin Guardianship Task Force, 2019, https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper2.pdf).

When an organization is serving as a guardian, the actual actions taken on behalf of the dependent are taken by individuals acting as delegates of the organization. The best way to authorize these guardian delegates is using delegation credentials, covered earlier in this chapter. This way, each action taken on behalf of a dependent can be cryptographically verified as being taken by an authorized delegate on behalf of an authorized guardian organization.

9.11 Certification and accreditation

How will you know that you can trust a particular digital wallet or digital agent application? Given the highly personal and private data these applications will be storing and exchanging—and its high value to everyone from marketers to criminals—users will want some surety that the design and engineering are safe and their information isn’t being leaked or shared inappropriately.

The standard solution for this kind of requirement is certification and accreditation programs such as those that exist for other categories of secure hardware and software like smartcards and hardware security modules. For particularly sensitive applications, such as banking or healthcare, you may have no choice but to use certified wallets and agents for your own safety.

However, this raises serious questions about user choice, self-sovereignty, and fair competition. Who gets to set the certification standards? (These are often tilted in favor of large industry players.) Who is going to accredit the accreditors? (Too often, these programs become slow and bureaucratic.) How much review is needed? (Having a trusted third party review an application for security or privacy flaws can be very expensive.)

Most of all, is it fair to ask Bubba, the masterful developer of Bubba’s Wallet, to pay a third party $5,000 to certify his application? What if the amount is $50,000? $250,000? Higher? Will the cost of certification be so high that it stifles the innovation needed in the SSI digital wallet community?

And finally, who gets to provide the digital “seal of approval” that end users can trust to know that the hardware and/or software for a digital wallet and agent has been certified successfully and has not been tampered with since then? These questions are the perfect lead-in to the Wallet Wars.

9.12 The Wallet Wars: The evolving digital wallet/agent marketplace

Apple has recently registered a number of patent claims across the general field of “verified claims of identity” which have quite rightly attracted some attention... I think these applications are really important and that the fact that Apple wants to control means of presenting and verifying “identity” through devices, including iPhones, is a signal to the industry that the wallet wars are about to heat up.

—Dave Birch, Forbes, 29 August 2020 [1]

In the early days of the modern (post-web) internet, there were two distinct periods: the two Browser Wars. 1995-2001 saw the shift from Netscape to Internet Explorer (IE). Antitrust cases didn’t save Netscape, and IE ended up dominating. In 2008, the introduction of Google’s Chrome changed the field again. As of early 2019, Chrome and its Chromium engine-based brethren make up more than 70% of web browser activities—no other major browser exceeds 10% usage. Even Microsoft threw in the towel on its engine, adopting Chromium for its Edge browser in 2020.

Very little revenue has ever been claimed for the sale of web browsers. However, billions have been spent on R&D to create baseline capabilities to support browsing—and the underlying monetization regime that supports the commercial internet. The reason is simple: web browsers are a required internet tool, and having your eyeballs on a vendor’s browser gives the vendor enormous power in the market.

A similar war is brewing over digital wallets—one that may eclipse the competitive landscape of web browsers. We will quickly explore three dimensions of these upcoming Wallet Wars:

• Who are the players that will attempt to influence or control your wallet (and agent)?

• What aspects of your wallet are they trying to influence and control?

• How they will exert this control and influence?

9.12.1 Who

In any large-scale shift, one of the most important things to understand is who the main players are and what they are attempting to accomplish. In the Wallet Wars, the players are diverse:

• Governments and nation-states —Regardless of the level of freedom a nation-state provides, it will want to control and influence some key aspects of the digital wallets used by its citizens.

• Big tech —The vast majority of big tech is heavily reliant on targeted advertising while espousing that they support privacy for all. As we adopt digital wallets and agents for more of our daily activity on the web, big tech may lose the ability to apply surveillance techniques to target us. They will adapt, but they will want to shape the battleground in their favor.

• Telcos —As the telecommunication business becomes more and more commoditized and telcos become pure data-pipe providers, they too are looking for a competitive advantage. And they have the benefit of already having a direct billing relationship with us.

• Equipment and OS manufacturers —Apple, Android, Samsung, Huawei, and others who build our devices (and the operating systems that run them) stand to be in a strong position of control. They have access to the lowest-level control points, starting with the specialized hardware (secure enclave; trusted execution environment) needed to support encryption, key management, and data availability. They also provide the layers of APIs that apps need to access these capabilities.

• Financial institutions and payment networks —Our current physical wallets and the early proprietary digital wallets (Apple Wallet, Google Pay, etc.) are centered around making payments easier while also capturing valuable intelligence about where we spend our money. This incentive will only increase as SSI-enabled digital wallets become a constant tool in all our digital relationships and communications—which may give these players an even bigger role in our increasingly digital lives.

9.12.2 What

This chapter has provided a long list of the capabilities that digital wallets and agents provide. The Wallet Wars will likely focus on certain extra-strategic capabilities:

• Security and encryption —The underlying hardware (secure enclaves; trusted execution environments) and OS will be critical. Defining the highest levels of security will likely require a small set of hardware components that are certified and accredited for certain uses (e.g., digital passports, payment tokens).

• Third-party insertion —Many services from digital wallets and agents can be performed peer-to-peer without any intermediary or third party required. However, there are many cases where third parties can add value or can be inserted to help even if they are not strictly needed. They are points of control and influence.

• Payments —Payments are already a ripe area for consolidation. “Old tech” payment providers (Mastercard, Visa, Amex, China UnionPay) and “new tech” (Stripe, Square, PayPal, Apple Pay, AliPay, WeChat Pay) are all vying for a “top of wallet” position. This will intensify in our digital wallets.

• Certification and accreditation —As discussed in the previous section, knowing whether we can trust “Bubba’s wallet” will become a key consideration of many governance frameworks (see chapter 11). As the industry matures, we may have no choice but to use an accredited wallet and agent for certain highly secure connections, credentials, and transactions, e.g., obtaining a digital version of our passport or making high-value payments.

• Integration —Many of us choose smartphones today because of how seamlessly they are integrated with many other aspects of our digital lives (laptops, smartwatches, cloud storage, email, calendaring, contacts, intelligent assistants, and so on). The same may apply to choosing a digital wallet and agent.

• Portability and self-sovereignty —This is a fascinating dimension of the competition between digital wallets and agents. As repeated multiple times in this book, “If it’s not portable, it’s not self-sovereign.” As much as digital wallet vendors will want to add special features that entice us to use their wallet, if they try to lock us into those features, they lose out on this feature.

9.12.3 How

Like the Browser Wars, the strategies and tactics of the Wallet Wars are likely to be manifold. Some chess moves will be obvious, while others will happen in the background and won’t be understood until much later. A few of the chess pieces are as follows:

• Standards —Anyone who has worked on them knows how open standards can easily be weaponized. There are many tactics for doing this: rushing standards to market, slowing them to a snail’s pace, watering down features to such a low common denominator that they aren’t useful, and so on. Even if the standards effort is well-intentioned, premature standardization can be a problem, especially for a technology as young as SSI. As shown in figure 9.6, standards and protocols take time to evolve. (For a full treatment of this topic, see Darrell O’Donnell, “Protocol Evolution,” Continuum Loop, 2018, https://www .continuumloop.com/protocol-evolution.)

• Regulation —Identity and money are two facets of our lives in which governments have been involved since the dawn of civilization. This probably will not change with digital wallets. Some role may be justified—at times. The hard part will be setting the boundaries for what is appropriate versus what is overreach.

• Open source projects —As open source becomes more prevalent, players are beginning to create new projects or shift existing projects to meet their goals. Altruism is great, but this is one gift horse you should look in the mouth. Examine the incentives of the sponsors and contributors. Are they all contributing to the good of the internet? What are their other objectives, and do they align with yours?

• “Freeware” and limiting functionality —Free tools have become the norm on the internet, but, as we know, nothing is ever truly free. We pay with our attention, our data, or both. With digital wallets and agents, the bargain is different than with websites and digital advertising. It will be fascinating to see what new bargains digital wallet/agent vendors will offer in the land of SSI.

• Convenience and usability —Ultimately, the best UX that provides the most value from digital wallets and agents is likely to win. Who will drive that UX? Will it be the same for everybody, or will it have many different niches and flavors? This is likely where the Wallet Wars will be won.

Figure 9.6 Protocols and standards often take years to evolve in order to reach broad adoption.

This chapter has covered an enormous amount of ground on the subject of digital wallets and agents. These are the key takeaways:

• SSI digital wallets are conceptually very similar to physical wallets except for the credentials they hold, and the functions they can perform will be much smarter.

• Every digital wallet is paired with a digital agent: the software module that mediates all interactions between the wallet, the user, and other agents.

• SSI digital wallets differ from previous generations of digital wallets because they follow different design principles, including being portable and open by default, being consent-driven, using privacy by design, and using security by design.

• An SSI digital wallet’s basic anatomy includes four primary agent functions (messaging, routing, backup and recovery, and secure storage) and two secure storage functions (encrypted storage and a key management system).

• Standard features of most SSI digital wallets include notification and user experience; receiving, offering, and presenting digital credentials; revoking and expiring credentials; authentication (login); applying digital signatures; and handling backup and recovery.

• Backup and recovery are critically important for SSI digital wallets because there is no higher authority to fall back on. They must include an automatic encrypted backup function and multiple options for recovering a lost, stolen, damaged, or hacked wallet, such as offline recovery methods (e.g., QR codes or cold storage devices); social recovery methods, where your recovery key is cryptographically broken into pieces and shared with trusted connections; or multi-device recovery methods.

• The SSI digital wallet space is evolving very rapidly, and advanced features that we see coming include multi-device support, multi-language support, offline operations, anti-coercion and data safety, compliance monitoring, secure data storage support, emergency data access, and insurance options.

• Digital guardianship requires special guardian wallets that can be hosted in the cloud and include special features such as biometric verification, delegation credentials, and automated enforcement of guardianship governance policies to prevent abuse.

• Certification and accreditation programs for digital wallets and agents will be inevitable given the highly sensitive data they handle and the potential for hacking or abuse. The big question is whether these programs will evolve in a way that is compatible with an open, fair, competitive market.

• In the next evolutionary stage of the internet, SSI digital wallets are expected to be as strategic as browsers. This means the Wallet Wars will see many of the same competitors and tactics—if not more so. Pay attention: self-sovereignty is what is ultimately at stake.

The function at the very core of digital wallets—key management—is so important that we made it the subject of the next chapter.

SSI Resources We invite you to learn more about the evolution of digital wallets at https://ssi meetup.org/state-digital-identity-crypto-wallets-darrell-odonnell-webinar-22.

Reference

1. Birch, David G.W. “Apple Pay Was Not Disruptive, but Apple ID Will Be.” Forbes. https://www.forbes.com/sites/davidbirch/2020/08/29/apple-pay-was-not-disruptive-but-apple-id-will-be /#52310fb44d0f.