“Immunity Passports” and Verifiable Credentials: a Response to Critiques
Elizabeth Renieris, a former colleague who I greatly respect, Dr. Sherri Bucher, and Christian Smith recently published a must-read article entitled “The Dangers of Blockchain-Enabled “Immunity Passports” for COVID-19.” Their analysis is well researched and raises important points which should act as a caution to anyone developing immunity passport solutions.
As the founder of a company that more than a hundred customers use to implement verifiable credentials, I see two primary points worth clarifying amidst the otherwise tremendous analysis in the article. First, I am aware of no technologists in the verifiable credentials community “racing ahead” to build immunity certificates, although there is plenty of other activity. Second, the concerns raised about the technology do not apply to verifiable credential solutions that employ best practices for implementation. I hope I can add to the conversation in a way that will enlighten readers as much as the authors’ article has.
Immunity Passports
The first and most important point I could hope to convey to the authors is that deploying immunity passports is not the goal of the verifiable credentials community or related initiatives.
Take my company for example. There are now more than 15 groups working with us at Streetcred ID to deploy verifiable credentials to address the COVID-19 pandemic. And despite sensational headlines, none of them are actively working to deploy immunity passports. They are working on other verifiable credential applications — from HIPAA certifications for new contact tracers, to credentialing for medical doctors practicing telemedicine, to import/export compliance for critical supply chains.
I want to echo the following three points made in the article:
- Current SARS-CoV-2 antibody tests are highly unreliable.
- No one knows if, or how, exposure to SARS-CoV-2 confers subsequent immunity.
- The road to a COVID-19 vaccine is long, winding, and uncertain.
It is clearly too early to deploy immunity passports. Additionally, it may never be a good idea to deploy immunity passports.
However, the question should be asked: What if we get reliable antibody tests, understand better the science behind immunity, and/or develop a reliable vaccine? In other words, what if circumstances change? It is wise to engage with public policy/health, medical, and technology experts now, as Dakota Gruener, Executive Director of ID2020, puts it in her piece “Immunity Certificates: If We Must Have Them, We Must Do It Right”:
There is significant value to proactively exploring the concept of immunity certificates and ensuring that, should such programs move forward, appropriate technical and regulatory safeguards are established from the outset.
Don’t Ignore Best Practices
The authors raise valid concerns about the technical underpinnings of immunity passports that must, and I believe can, be addressed using current best practices in the industry.
Online Use
The authors argue that verifiable credentials (VCs), DIDs, and related APIs are built assuming a constant internet connection and online use:
Credentials for in-person use would ideally be designed to work on mobile devices similar to contactless payments such as Apple Pay. However, the web standards on which VCs are based offer nothing to support this capability.
While it’s true that the web standards underlying VCs themselves don’t natively support this, it’s straightforward for an application developer to support this capability. At Streetcred, we’ve utilized Bluetooth + Wifi (the same tech that powers Apple’s AirDrop) to facilitate peer-to-peer verifiable credential exchange to nearby people. The underlying standards are fundamentally transport-agnostic; there is nothing preventing use of NFC, QR code, Bluetooth, etc.
It’s worth commenting on the following statement, too:
Ensuring offline usability requires eliminating dependencies on remote resources, such as public keys linked to blockchains.
As long as there is connectivity at some point, the public key directory (in this example, a blockchain) can be cached locally, enabling offline usage. We’ve built this capability at Streetcred, too, and are working with several of our partners on deploying it in low-connectivity environments on three different continents.
And even if the technology was totally reliant on connectivity to function, that wouldn’t mean the technology isn’t useful. It just means policymakers and implementers would need to pay additional consideration to issues of accessibility. As Amos Doornbos points out, all technology will leave out somebody. Regardless of a dependence on connectivity, accessibility should be top-of-mind for application developers, especially for critical technologies like verifiable credentials.
Key Management
The authors touch on both private and public key management challenges. On public keys managed on a blockchain, they identify critical risks:
[It] creates additional obstacles to offline credential use and verification, while facilitating potential collusion, passive surveillance, and re-identification through data inference.
This is a quintessential example of impeccable analysis applied to a varied landscape. There are indeed approaches to verifiable credentials that use the blockchain to manage public keys of individuals, exposing them to these and more risks. However, these points do not apply to projects that employ best-practices to avoid natural persons having public DIDs on a blockchain — at least until the risks can be worked out. Best-in-class projects like Sovrin go so far as to explicitly prohibit public DIDs for natural persons.
On private keys, the authors assert:
Blockchain solutions have failed to provide credible methods of private key management. Without this, users are subject to elaborate inconveniences that also negate the security assurances expected from credentials.
Private key management solutions exist in a myriad of forms. The degree of inconveniences, security, and user-control depend on the implementation. The simplest key management solution is a complete custodian model. Coinbase has done a great job doing this for cryptocurrencies. A hybrid model could also be employed (this is the one used in the Streetcred Wallet today); a user can back up an encrypted copy of their wallet to a secure cloud or export the wallet to keep in storage of their choosing. Completely decentralized solutions indeed require a great deal of technical knowledge and/or inconvenience but importantly exist for those who don’t want to rely on anyone other than themselves to safeguard their data.
Security Protocols
The authors note that the scope of the W3C recommendation for verifiable credentials doesn’t include security protocols. This is by design — the ideal recommendation is the minimum set of standards that will accomplish the goal and achieve interoperability, not prescribe implementation details. The VC standard is a data model and nothing more.
…there is currently no strong assurance that the presenter of a credential is its subject… Effectively, the door is wide open for improperly borrowing or stealing [immunity passport] credentials.
Let’s set aside the technology for a second and look at a real-world example. What is the assurance that a presenter of a driver’s license is its subject? Is it our trust in the DMV combined with the person’s picture on the card? Or is it the watermarks and other anti-counterfeiting features? Is it all of the above? Isn’t the door wide open for me to improperly borrow or steal a relative’s credit card too, to use another example? Nevertheless, that doesn’t mean driver’s licenses, credit cards, and other real-world credentials aren’t useful.
Verifiable credentials aren’t a miracle technology that will forever eliminate fraud. Accepters of credentials should understand their risk tolerance and request verifications according to their policies. Using best practices, there are three additional advantages of verifiable credentials over their paper and plastic counterparts:
- Private biometrics: Credentials can be linked to biometrics, either in the form of a photo (like what exists on a physical ID card) or other, more advanced privacy-preserving biometric technologies like biometric hashes.
- Non-transferability: Credentials are either non-transferrable or evidently/auditably transferrable.
- Linking: Credentials in a wallet are linked to the other credentials in the wallet. This means that a verifier can request two or more different credentials which are provably linked. It’s the digital equivalent of requesting two forms of photo ID for extra strong assurance.
Blockchain
After the hype of 2016 cascaded into the “Trough of Disillusionment,” blockchain has become little more than a buzzword. The authors assume the blockchain is much more important than it actually is. Although promoted heavily several years ago, often to drum up interest in ICOs or press, blockchain isn’t necessary for verifiable credentials. It says so right in the spec at the W3C. The spec writes:
Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers.
In the case of best-practices for verifiable credentials, blockchain is used as a decentralized public key infrastructure. Of course, the traditional DNS system complete with certificate authorities and ICANN could accomplish much of what is done with Decentralized Identifiers and the blockchain. But that infrastructure is decades old and comes with its own cost, scalability, performance, privacy, data protection, and governance implications. Using DIDs on a blockchain comes with a different set of trade-offs. Implementers can make their own decisions on tech stacks, and there is a reason so many choose DIDs.
Conclusion
It is clearly premature to deploy immunity passports. But that doesn’t mean we should stop trying to determine whether/how they will be useful. To again quote Dakota Gruener,
Proactive adaptation of existing, purpose-built, privacy-preserving technology (verifiable credentials), grounded in respect for equity and human rights, offers a means to protect society from a resurgence of the disease, while safeguarding individual privacy and civil liberties.
She goes on to clarify how these systems must be implemented.
To protect individuals from surveillance, discrimination, fraud, or exclusion, we must ensure that systems developed to serve these purposes are private, secure, and accessible — and are developed using open-source technology and open standards for interoperability and universal access.
The paragraph I suggest is missing from the authors’ the article is this: Most tools, from nail guns to sledgehammers to semi trucks, are wonderful when used for their intended purpose and very dangerous when used incorrectly or nefariously. Technologies like verifiable credentials and blockchain are tools at humanity’s disposal to address the pandemic we’re all facing. If implemented poorly, the authors’ doomsday scenario will come to pass:
Our right to privacy; freedoms of association, assembly, and movement; our rights to work and education; and otherwise seriously limit our freedom and autonomy, even where not compulsory.
If circumstances evolve to warrant immunity passports, and if they’re implemented properly, we’ll see Dakota’s more optimistic scenario play out,
Immunity certificates may be an essential next step to reversing the economic and social consequences of COVID-19. Proactive use of intentionally designed technology — decentralized, privacy-protecting, and built on open standards — provides a route to the creation of such certificates without surrendering privacy.
