The adoption of easy to use digital wallets to store cryptographic keys and attestations presents both opportunities and pitfalls.
As the comfort level with online is massively accelerated by our pandemic-fueled reliance on digital interactions, there is an increasing realization that easy to use digital wallets will play a crucial role in enabling those interactions. You can get a sense what I mean by this explanation of the role of wallets by Timothy Ruff and an understanding of the current state of digital wallets in this webinar with Darrell O’Donnell.
At the same time, I believe there are three areas that we need to consciously pay attention to in order to ensure that the future does not become a collection of proprietary vertical cylinders of excellence (silos): pipe and payload, vertical integration, and occasional connectivity. Let me take each one in turn below.
Pipe and the Payload
The three P’s that need to be addressed when it comes to multi-vendor, multi-platform interoperability are Pipes (the protocols used to carry data between systems), Payload (the format of the data carried inside the pipes), and Policy (the controls and constraints applied to the pipes and payload). The term application programming interface (API) roughly map to a combination of pipe and payload.
Where this applies to a wallet is that it has an API that in very concrete terms defines the pipe and the payload to be used by an Issuer of attestations, certifications and licenses in order to store them in the wallet, and another API that defines the pipe and the payload to be used by the Holder of the Wallet to present those attestations, certifications and licenses for validation and verification by a Verifier.
However, APIs, when left undefined, ill defined, to be defined or proprietary have been used to lock Issuers and Verifiers to a particular vendor’s infrastructure or platform. And that particular game is very much afoot right now.
You don’t have to look any further than the clearly articulated scope of the work that is currently going on at ISO to define the APIs for a Mobile Driver’s License (mDL) to understand the potential for future vendor lock-in:
This document standardizes the interface between the mDL and mDL Reader, and the interface between the mDL Reader and the issuing authority infrastructure.ISO/IEC DIS 18013-5(en) — Part 5: Mobile driving license (mDL) application
What is clear about the above is what is left undefined, or left to be defined by someone at some other time: the interface between the “issuing authority infrastructure” and the mDL. By leaving this open at this time and not in scope, we can expect vendors to cite this lack, while offering their proprietary APIs to mDL Issuers and by doing so seek to lock them into their particular platform.
While I am sure that there are vendors out there that will resist their nature, a proactive step that Issuers and Verifiers can take is to include some prophylactic language in their technology acquisition that ensures that all APIs that are presented to the Issuer and the Verifier be publicly documented, patent free, royalty free, non-discriminatory, available to all, and free to implement using widely available and supported programming languages.
Wallets that are vertically integrated are purpose built and deployed by a single organization and store and manage only the credentials issued by that organization. This type of approach provides an easy path to the Issuer and their technology provider to control the end-to-end process and selectively support standards.
As an example, they may choose to support a standardized verification capability but use proprietary mechanisms for connecting to the issuance infrastructure and for credential data storage in the wallet.
What is concerning about this type of approach is that it limits adoption of the digital credential because of the lack of broad usage and requires a person to carry an app (should we even call them wallets?) for each credential. This ends up being a variation of the big box retailer issued credit card that can only be used at that store instead of a globally usable Visa, MasterCard or Amex. Hello mDL!
Given the existence of open, well understood standards such as W3C Verifiable Credentials and W3C Web Authentication, the rationale to go vertical often tends to get cloaked in the narrative that end-to-end control means higher security.
I tend to be skeptical here but do think that there needs to be a lot more work that needs to be done to assess the security, privacy and interoperability properties of specific Wallets before an Issuer makes a risk-based decision to use one outside their sphere of control.
With the current generation of technologies, the distinction between online/off-line and web/native wallets tend to blur. What is important is that the wallet will end up in situations with intermittent connectivity and that it needs to be able to continue to operate.
This may also have implications for the variety of protocols that the Wallet needs to support. CHAPI? NFC? BLE? This is an area where I have very limited expertise in, so this is an area that I am tracking and learning about currently and would love to learn from folks who are moving the needle here.
This is an interesting and dynamic area with a great deal of promise. It presents an opportunity to organizations both large and small in how we all interact digitally going forward. What is important to keep in mind is that interoperability does not mean commoditization but instead a common baseline of functions that provide a minimum and useful set of functions across multiple vendors.
The days of locking in customers by going around their problems are coming to an end. What customers are now looking for vendors to do is the hard work of building extensibility points on top of an interoperable baseline that can differentiate them, and provide value to the customer. Are you ready?
cyberforge: random and relevant
The World Health Organization (WHO) on “Implementation and management of contact tracing for Ebola virus disease” which has lessons to apply to the coronavirus on “… general considerations for contact tracing; case definition; planning and preparation; personnel; implementation, and tools for contact tracing”.
Scott Galloway, Professor of Marketing at NYU Stern, is always fascinating to listen to; never more so than in “United States Corona Corps”.
The cryptographic implementations of the joint Apple/Google BLE based contact tracing application looks to be built on an earlier version of DP-3T. The authors are urging Apple/Google to adopt a later version with “enhancements that increase user privacy”.
The Future of Privacy Forum answers questions submitted by Members of the U.S. Senate Committee on Commerce, Science, and Transportation on “Enlisting Big Data in the Fight Against Coronavirus” (PDF).
Bill Gates on the scientific advances we need to stop COVID-19 across five categories: treatments, vaccines, testing, contact tracing, and policies for opening up.