This post is an excerpt from an upcoming report entitled The Current and Future State of Digital Wallets, which is being shared here as a 16-part series. To receive a copy of the report, please register here and we will get the current draft sent out immediately and a PDF of the final report when it is ready. This is the fourteenth post. For the first post click here, for the previous post click here, and for the next post click here.

The early successes with Digital Wallets will be simple application of the technology to meet very specific use cases. Broad Wallet initiatives at this time are ill-advised. In order to make progress at this early stage, there are two recommended things to consider in building out a Digital Wallet strategy.

​Single-Purpose Use Cases

Generally applying a Digital Wallet to a single-purpose use case will be the simplest road to success. Examples include:

  • Using a Digital Wallet to receive and share a particular Credential that is generally painful when not done using Verifiable Credentials.
    • BC Government’s VON, which creates Verifiable Credential versions of corporate registrations, is a starting point. It will evolve to include permits, licences, and other Credentials that anchor back to the corporate registration. Interestingly, and appropriately, BC Government has currently avoided tying a Person to an Organization. This is partially due to the immature nature of applying Delegation via Digital Wallet. Once that issue is better understood they will likely move forward.
  • Using a Digital Wallet to meet a very specific use case with multiple parties. Here are some examples:
    • ATB Financial worked with IBM and Workday to prove out an employee onboarding/transfer use case. An employee Credential was issued by IBM through its HR technology partner’s system (Workday). That Credential was then used to open a bank account. Subsequently that bank account information was provided back to the employer (IBM) for automated salary deposit. The project proved out the utility of sharing high-quality, trusted information to automate processes. Past approaches would have required deep integration with systems and APIs. However, history has shown that even the largest of Organizations can only afford so much formal integration.
  • Using in basic form while advanced use cases evolve. There are foundational steps that can be taken in any systems architecture approach. These should be pursued and be aimed at very simple but broad use cases.
    • CULedger is using a basic Verifiable Credential that will be issued by credit unions to provide a common authentication Credential. This Credential, and the process behind it, promises to create a foundational capability that allows credit unions to reassert control of the authentication process. The current authentication processes are fractured and inconsistent with many credit union members needing to manage numerous usernames and passwords. As CULedger evolves there are community Credentials planned but there is understanding required to see exactly how far this goes.
  • Using a mini-wallet approach may be useful where a single credential is stored inside an application for later use. This approach can be used to provide a second-factor authentication (2FA) strategy for mobile applications. Instead of a full Digital Wallet, in this case a library is used to embed the capabilities.

The leaders that are pursuing the above example approaches early on are not ignoring where Digital Wallets can take them. Each of the mentioned teams using the single-purpose use cases is using them as building blocks to prepare for their next steps in the space. Focusing on one particular use case allows them to achieve incremental progress that they can build on. They build momentum.

​Backup & Recovery is Mandatory

Whatever solution is deployed there is a key weakness in all Digital Wallet applications that this study found. None of them have viable backup strategies. While data can be backed up, the processes required are extremely onerous for multiple reasons:

  • Frequency of Backup – the Digital Wallets change contents regularly, which means the backup files need to be updated. As Digital Wallet use increases these updates could be constant as messages, notifications, and consents are used.
  • Loss of Keys – the use of mnemonics as seeds to control a Wallet are a beginning step, but asking someone to securely store this seed is not realistic.
  • Complexity – managing a Digital Wallet at this time is complex, complex enough that very few, your author not included, will safely use Digital Wallets beyond trivial use cases.

​Simple Trust Hubs

Managing the list of Issuers that you can trust is crucial to early success. If you don’t know that a particular Issuer is “official” and/or “trusted” you can’t do much with the contents of a Digital Wallet.

Until there are formal standards and approaches to managing the definitive lists of Issuers, any systems being created need to manage the Issuers that are “trusted”. At a small scale this is quite manageable but as different bubbles of activity connect, complexity will emerge.

Using a configurable list of Issuers, managed by a repeatable and trusted process will be crucial.

This post is part of a 16-part series. This is the fourteenth post. For the first post click here, for the previous post click here, and for the next post click here.