New Hyperledger Indy updates pave the way for verifiable credentials to be issued and read on different networks, affirming Hyperledger as the most advanced framework for interoperable, decentralized identity
Earlier this year, the Government of British Columbia announced the “Indy DID Method Code With Us” challenge. The goals were to align the content that can be written in the DIDDocs published on Hyperledger Indy networks with the current World Wide Web Consortium (W3C) Decentralized Identifier (DID) Specification and to add a namespace element to DIDs (and other object identifiers) published on Hyperledger Indy networks, so users know on which of the many Hyperledger Indy networks the DID was created.
Hyperledger Indy is an open source project housed at the Hyperledger Foundation providing the codebase to create distributed networks, purpose-built for SSI and verifiable credentials. Networks built on Indy are some of the most mature and tested networks with self-sovereign identity (SSI) capabilities; but since they were developed before the publication of the World Wide Web (W3C) DID Specification, they needed to be brought into alignment.
While the Indy DID Method began as a community development effort within Hyperledger Indy, it needed a push to completion; hence the Code With Us challenge from the government of British Columbia. Indicio was awarded the challenge and went on to develop and complete several of the remaining components.
The result is that a credential issued using any Hyperledger Indy network (such as Indicio, Sovrin, Findy, Bedrock, IdUnion, etc.) can be processed by any verifier. This is because the objects in the verifiable presentation reference the Hyperledger Indy network used by the issuer. The Indy:DID Method lays the groundwork to make this possible.
This advancement in interoperability is significant. While issuers still need to be anchored in the specific Indy ledger of their choice, holders can seamlessly receive verifiable credentials from issuers rooted in different Hyperledger Indy networks, and be able to create verifiable presentations from any combination of those credentials. Likewise, verifiers will be able to verify presentations that include claims derived from credentials rooted in multiple Indy networks. The Indy:DID Method paves the way for Hyperledger Indy credentials to scale by allowing Indy networks to seamlessly interoperate, creating a global “network of networks” effect.
With the groundwork complete, networks and agent frameworks now need to incorporate the Indy:DID Method. This community adoption will increase the viability of the Indy and Aries project stack and position it to be the globally dominant way to issue and share verifiable credentials in a multi-ledger world.
The Indicio team would like to thank BC Gov for funding this work and Dominic Wörner, another contributor to the Code With Us challenge, for his work on Indy VDR.
Want to jump start a career in blockchain development? Ready to build hands-on skills developing leading-edge open source technologies? Looking to work directly with mentors who are invested in you and your work? Then the Hyperledger Mentorship Program is for you.
Now in its sixth year, the Hyperledger Mentorship Program provides a structured and guided learning opportunity for anyone, at any career stage, looking to get started in the open source movement. With full and part time options, fully remote work and a stipend, the projects are designed to be a pathway to becoming a contributor to the Hyperledger community that work for students, people in career transition and anyone else who wants to develop or sharpen their knowledge of cutting-edge blockchain technologies. Applications are now open.
This year, the Hyperledger Mentorship Program has grown to 30 planned part and full-time projects covering a range of technologies, challenges and technical difficulty levels and includes non-development projects such as Ecosystem Analysis and Developer Marketing. Each project is designed and proposed by active members of the Hyperledger community. Those who propose the projects serve as the mentors and work closely with their mentees on developing a project plan, setting milestones and solving problems. Mentees can expect regular evaluations and feedback. For more about the program, including the schedule and stipend details, go here.
Over the last five years, more than 70 mentees have completed Hyperledger Mentorship projects. Each of these mentees have made concrete contributions to Hyperledger projects and built important connections in the community. Some, like Bertrand Rioux, have gone on to become mentors themselves:
“I was accepted into the Hyperledger mentorship program last year after seeking a community to help advance my professional goals of developing software for climate action. I was fortunate to find a diverse group of mentors that helped me build the knowledge and skills I needed to effectively contribute to the Hyperledger open source community and to have the opportunity to develop technical expertise in a field I was actively working in. In addition to delivering a secure identity management solution for a Hyperledger Fabric Network, I started contributing my own ideas to the open source operating system for climate action. As a result, I am now taking a leadership role in the community. In addition to serving as mentor in this year’s program, I proposed a project on reducing waste emission in the oil & gas industry that was accepted.” – Bertrand Rioux, Independent Energy Consultant and Mentor for the Multiple Data Integration to Hyperledger Fabric Climate Accounting Network project
The Hyperledger Labs blockchain-carbon-accounting project includes a Hyperledger Fabric network for recording the carbon and Greenhouse Gas (GHG) emissions that cause climate change. Since there are many activities that cause such emissions, the network is designed to accept data from multiple sources of measurements. In this project, we will demonstrate integrations from measurement sources with blockchain networks by integrating the ThoughtWorks cloud computing emissions calculator, the NREL OpenPath mobile application, and other web- and mobile-based API’s sources to turn instrumented readings into emissions measurements. It will leverage previous projects involving Hyperledger Cactus, Vault security engines, and client security for Hyperledger Fabric.
The expected outcomes of this project are
Successful integration of the mobile apps and API’s with Hyperledger Fabric
Benchmark comparison of Hyperledger Fabric and alternatives
Documentation and tutorials for integrating future data sources
Hyperledger Cactus support ledger Interoperability but use a local deployment for testing; Hyperledger Bevel supports production-worthy deployments. This project aims to support Cactus deployment using Bevel to demonstrate production-like usage of Hyperledger Cactus.
The steps will be following:
Deploy a Hyperledger Fabric network using Bevel on a Managed Kubernetes cluster
Deploy a GoQuorum network using Bevel on a Managed Kubernetes cluster (can be the same cluster for simplicity).
Make changes in Hyperledger Bevel code to deploy the Cactus connectors in both the above networks.
Run Cactus test cases.
The expected outcomes of this project are
Successful Interoperability testing using Cactus on production like DLT networks.
Update to Hyperledger Bevel code to automatically deploy the Cactus plugins.
Update to Documentation of Bevel and Cactus.
Detailed tutorials and learning materials which would benefit Bevel and Cactus communities.
One of the key use cases of blockchain integration is asset bridging: in essence, “locking” an asset (typically, a native coin or token) in a smart contract on its authoritative ledger and making available corresponding, newly minted (wrapped/shadow/…) assets on another. By now, bridging is supported by quite mature solutions in the cryptoworld; however, the same is not true for “consortial” distributed ledger technologies. At the same time, such functionality can be expected to become an important requirement in the not too distant future: for instance, a central bank may choose to create a high performance, Hyperledger Fabric-based Central Bank Digital Currency (CBDC) ledger with a strongly controlled set of “smart contracts,” but allow controlled “bridging out” of the currency to dedicated distributed ledgers of industrial/enterprise cooperations.
Last year, a CBDC prototype with such functionality was created at the Dept. of Measurement and Information Systems of the Budapest University of Technology and Economics (BME), in a research project supported by the central bank of Hungary (MNB); our initial experience with a custom Hyperledger Cactus and TokenBridge based solution showed that this is a problem worth more targeted experimentation and systematic R&D.
The expected outcomes of this project are
Report on asset representation in Hyperledger Fabric and mapping approaches to standard Ethereum tokens
Report on bridging approaches and technologies and their applicability for bridging from/to Fabric
Requirement specification
Design specification
Prototype implementation and small demo of bridging at least ERC-20 or ERC-721 to Ethereum – and back
Develop a connector that provides both synchronous and asynchronous modes of interacting with a running Hyperledger Besu node. The connector would act as an interface between an enterprise application and the Hyperledger Besu node for data ingestions and it could provide event subscription options.
The scope of the project would also include an end-to-end test on a sample network.
The expected outcomes of this project are
Design and implement the connector.
A new Hyperledger Labs project is proposed with a documentation.
As conceptualized and standardized by the W3C, the Verifiable Credentials protocol is one of the three pillars of Self-Sovereign Identity, together with the Decentralized Identifiers protocol (DIDs) and Distributed Ledger Technology (or Blockchain). The project aims to design and build a verifiable credential registry (VCR) on GitHub repository, namely GitHub-based Verifiable Credential Registry (GVCR), by leveraging existing GitHub APIs, and other open-source tools provided by other Hyperledger projects, such as Hyperledger Aries, Hyperledger Indy, and Hyperledger Ursa. The basic architecture is already built. For more details about the conceptional design and workflows, please refer to the GitHub repository GitHub-VCR.
The expected outcomes of this project are
A verifiable credential registry based on one or more GitHub repositories.
Command-Line utility to automate the process of verification of a credential.
Proper test cases and documentation.
Codebase maintained with proper read me document.
The Hyperledger Summer Mentorship Program is part of the Linux Foundation’s overall commitment to mentoring. The application process is being managed through LFX Mentorship, a platform created by the Linux Foundations to train future open source leaders.
Without interoperability, you wouldn’t be able to read this article. Websites, computers, and servers must be able to recognize and share information with each other, and shared standards and protocols allow them to do so, thereby giving us the web. On a smaller scale, companies have their own intranets, and, on the smallest scale, you might have your own private thumb drive for personal documents that can interact with whatever machines you typically work on.
Interoperability is not a technological given or an inexorable process. It is a choice that needs to be actively made, and it can sometimes take considerable effort to make work. Think of electronic health care records and the years it has taken to make it easier for a patient to access their health data, something originally provisioned in a 2000 Privacy Rule to the Health Insurance Portability and Accountability Act (HIPAA) of 1996.
Crises, however, can accelerate the slog to technological convergence—and that’s precisely what we’ve seen as a result of the global COVID-19 pandemic. In April 2021, a data-sharing provision of the 21st Century Cures Act came into effect: Patients must be able to have direct digital access to eight categories of clinical notes in an electronic health record, notably—given the need for COVID testing—lab test results.
Cometh the legislation, cometh the tech. Indicio and SITA had already been working on a decentralized, verifiable credential solution to integrate passenger health data with air travel in a privacy-preserving way. Built on Hyperledger Indy and Hyperledger Aries, the technology solved the problem of patient privacy by eliminating the need for a centralizing party to store patient data in order to facilitate verification.
With the Cures Act provision, there was now no obstacle to passengers in the US accessing their COVID test data directly from a Health Information Exchange in the form of a digital credential. They could use this credential to prove their test status without having to share personal information. In situations where it was important to know which test they had taken and when, they could choose to share this information with a verifier, such as the border control or health agency of the country they were visiting.
This solution is now known as the Cardea Project. Successfully trialed in Aruba, its codebase has been donated to Linux Foundation Public Health as an open source solution for sharing health data through verifiable digital credentials. It has an active community group, led by Indicio and Shatzkin Systems, that is working on expanding its features and, critically, its interoperability.
To do this, Cardea launched a hackathon for interoperability— dubbed an “Interop-a-thon”— in September 2021. The goal was to get companies using Aries agents to test those agents against a reference implementation of Cardea and each other. Over a half day, SITA, Liquid Avatar, IdRamp, GlobalID, Canadian Credentials Network, and Network Synergies all successfully interoperated. That’s the headline; the story, however, is that it took work to make this happen—it was an exercise in uncovering glitches, unexpected problems, and overcoming them. That’s what made the Interop-a-thon so valuable for all the participants—and that’s why Cardea is holding a second Interop-a-thon on March 17.
This time, in addition to agent testing, Cardea is going to field “out-of-band” invitations (a critical change coming to Hyperledger Aries at the end of March) and a simple reference implementation of machine readable governance (a way of adding governance rules at the agent level, thereby making governance portable and available offline).
Participants see interop-a-thons as a testing ground for interoperability, and therefore a way to ensure that the products and services they are building have the capacity to scale. This is a critical step toward achieving a network of networks effect. Not surprisingly, the number of participants signed up for the next Interop-a-thon is much greater than the first.
For Cardea, there are more and bigger trials on the way. And with each solution delivered, the scope for expansion becomes greater. If we can successfully implement a system for incorporating health data in travel, what about all the other clinical notes described by the Cures Act? What’s the roadmap to creating a decentralized health record?
This is the perfect challenge for an open source community to solve. And by testing the solution through an interop-a-thon, we can figure out how to make the many function as one.
“You’ve come a long way, blockchain!” declares Forbes in the 2022 Blockchain 50, an annual list that tracks how billion dollar companies from around the world are innovating with the technology. Now in its fourth year, the Forbes Blockchain 50 has evolved just as much as this market.
The mainstreaming of both cryptocurrencies and their underlying technologies have reshaped business around the world. For many companies on the list, the innovation comes from new models of investing and transacting in crypto markets. But, as Forbes put it, “Cryptocurrencies hog the spotlight, but blockchain’s biggest innovations are below the surface, saving billions each year for the world’s largest companies.”
For the companies on the list that have made blockchain technology a core foundation of their business operations, Hyperledger technologies, particularly Hyperledger Fabric, continue to be the standard. At least 13 companies on this year’s list have built their strategic networks on Hyperledger technologies, far outpacing any other technology or platform among these kinds of deployments.
Congratulations to Hyperledger Foundation members DTCC, Fujitsu, Nornickel, Oracle, Tech Mahindra, Tencent and Walmart for making the Forbes Blockchain 50 in 2022. Read more on how Tech Mahindra, Walmart and other member companies are using Hyperledger technologies in our growing library of case studies.
Hyperledger Indy and Hyperledger Aries are two of the popular open source repositories that can help propel development of decentralised identity products and services. Aries is a toolbox of several blockchain-agnostic repositories that allow for trusted online peer-to-peer interactions based on decentralized identities and verifiable credentials. The project grew out of work that was happening in Indy to create technologies for managing decentralized identity. Aries was moved to graduated status by the TSC in February 2021. Indy graduated in 2019 and provides a specific blockchain purpose-built for identity.
Seeing the growth in interest for these two projects, Hyperledger Foundation has partnered with member company Indicio and its team of deeply experienced developers and architects to develop this free, multi-course curriculum to help developers and architects gain a deeper understanding of decentralized identity, with a deep dive into Aries and Indy. Registration and preparation information can be found on this Workshops page.
These two four-hour, beginning level hands-on workshops provide opportunities to install and run the Indy and Aries components just like you would if you were making a real Indy-based network or Aries-based application. They introduce the necessary Git repos as well as how to use the Indy Command Line Interface (Indy CLI), run the Aries toolbox and create and issue a verifiable credential. They also introduce some current projects using Aries and Indy to help you accelerate your understanding of decentralized identity and build the skills necessary to successfully make changes to the underlying code with hands-on guidance to develop your own projects.
The first in the Hyperledger Foundation Community Workshop series, Intro to Decentralized Identity is a four hour online course to introduce the core concepts and principles of decentralized identity. As you progress, you’ll learn how to use a Hyperledger Indy-based network, be introduced to the Indy CLI, and install and run the Aries toolbox to create, issue, and verify a verifiable credential.
Topics also include:
Decentralized identity concepts and principles
The verifiable credential data model
Decentralized identity ecosystem
Introduction to network tools indyscan and SelfServe
Intro to Indy CLI and how to use the CLI to access a network
The second in the series is a four-hour course that advances your skills related to Hyperledger Indy node code and the Indy SDK. It also covers the commonly used cryptography libraries contained in Hyperledger Ursa, the Plenum ledger and how to interact with and change the repositories and code.
Topics also include:
Install and build with Indy SDK
Introduction to libindy, indycli etc
Indy VDR (replacement for Indy-SDK)
Making changes to Indy node code
Build and IndyTest the changes locally
How to get involved in the community further with chats, helplines, and meetings
Both courses do have several must-have prerequisites, including the installation of docker, installation of Indy-CLI, installation of rust, and the download of important repositories. This can be done independently, or you will have the opportunity to connect with instructors during pre-course office hours on a dedicated helpline.
These new courses are the first community workshops offered by the Hyperledger Foundation for free in an effort to expand the use, contributions, and maintainer community of Hyperledger Indy and Aries. Recordings of the courses will be made available at the conclusion of the instructor-led events.
Hyperledger is once again sponsoring the annual AnitaB.org Grace Hopper Celebration as a way of supporting leaders and future women technologists in our global community. Hyperledger and the Linux Foundation are committed to supporting women-led initiatives centered around recruitment and engagement like AnitaB.org.
This year, Hyperledger is putting its resources behind Open Source Day (OSD), an all-day hackathon for participants of all skill levels to learn about open source while contributing to projects designed to solve real world problems. OSD will be held October 1 as part of this year’s Grace Hopper Celebrations (vGHC).
During OSD, the women taking part will spend the day diving into the open source world to level up their skills and start contributing code. Participants will work in groups and with the mentors for hands-on learning, tailored to their experience level.
Hyperledger is an official Open Source Partner Project for OSD and is teaming with maintainers from four Hyperledger projects to introduce participants to its diverse ecosystem. Maintainers from these projects will on hand as guides to both the Hyperledger technologies and the code contribution process:
Hyperledger Besu, an Ethereum client designed to be enterprise-friendly for both public and private permissioned network use cases;
Hyperledger Cactus, a blockchain integration tool designed to allow users to securely integrate different blockchains;
Hyperledger Indy, a framework that provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers; and
For each of these projects, the maintainers have compiled an array of pull requests or tasks that are tagged as “Good First Issues” that participants can tackle as their initial code contributions to Hyperledger. These triaged, non-documentation requests include everything from bug fixes to enhancements to security plug-ins. For those who want to challenge themselves or move deeper into a project, the Hyperledger Cactus list is broken down based on level of experience:
We want to thank our maintainers Anastasia Lalamentik (FireFly), Grace Hartley (Besu), Justin Florentine (Besu), Linlu Liu (FireFly), Nicko Guyer (FireFly),Peter Somogyvar (Cactus), Renata Toktar (Indy), and Tracy Kuhrt (Cactus) for offering their time and expertise to OSD. They will play a vital role in welcoming the Grace Hopper community into the world of open source and setting them up for success as contributors to Hyperledger and other projects.
As the world continues to grapple with COVID-19, there is an upswing in interest in digital identity technologies and their potential to underpin new health passes, travel credentials and other pathways to restarting economies that are effective, secure, accessible and privacy preserving.
Stephan Curran’s post on Why Distributed Ledger Technology (DLT) for Identity? also offers a good explanation of sudden and urgent issues driving interest in identity and the role of Hyperledger technologies in delivering solutions.
Advances on these fronts are fostering important new developments. However, digital identity solutions are reshaping other industries as well. Read on for a sampling of Hyperledger-powered solutions that are in production now, bringing innovation to the telecom, supply chain, education and training and financial services markets:
Alastria ID over Red H+
Alastria ID, a project of Alastria, the Spanish association that promotes the development of solutions based on decentralized ledger technologies, is focused on decentralized identity management. It is a self-managed identity model based on the World Wide Web Consortium (W3C) Verifiable Credentials standard designed to facilitate compliance with the General Data Protection Regulation (GDPR) for individuals, companies, organizations and entities. The use of credentials issued on different networks will enable interoperability across multiple applications.
Telefonica and Inetum have partnered to implement Alastria ID in a Hyperledger Fabric production environment in Alastria. Named “red H+” (H+ network), this implementation gives more than 500 members of Alastria access to a production grade infrastructure based on Hyperledger Fabric technology. Red H+ offers a free of charge Hyperledger Fabric environment for Alastria members, designed for the deployment of proofs of concept or production projects without demanding requirements, and a production-ready paying platform for those members interested in having certain levels of service and personalised and guaranteed response times, as well as value added services such as Alastria ID.
(Note: You can learn more about Alastria’s mission to promote the digital economy and how the Hyperledger community is involved in this May 5 webinar.)
MemberPass®
MemberPass is a digital credential solution that enables financial institutions to instantly verify financial credentials seamlessly across all consumer contact points in a highly secure and privacy-preserving manner. It is the flagship product of Bonifii, the financial industry’s first verifiable exchange network designed to enable trusted digital transactions using open standards and best-of-breed security technologies. Because MemberPass is built on Hyperledger Indy, credit union members can retain full control of their private personal information. The credential is secure and flexible. It allows the member to reveal only the data necessary for a given transaction. (See more on MemberPass adoption here.)
SnapCert
SnapCert is a blockchain-based Credential Authentication platform for universities, colleges and institutes. Offered as a SaaS platform by Snapper Future Tech, SnapCert equips education customers to issue and verify credentials on a blockchain, ensuring no fraudulent credentials can be issued in their name.
Customers include Kushal, a social organization that trains unskilled labour under Indian government National Skill Development program. With SnapCert, verifiers can get real-time verification of Kushal credentials directly from the primary source of the data simply using the last four digits of the credential holder’s Aadhaar id and the name. The solution solves the problem of misplaced paper credentials and reduces the trust deficit by providing easy access to credible credentials that prove the holder’s construction training. It also helps Kushal manage long term record keeping for the skilled workers, connect stakeholders that need the data and increase transparency and ease of doing business.
SnapCert is built using Oracle Blockchain, which is powered by Hyperledger Fabric.
Trust Your Supplier
Built on Hyperledger Fabric blockchain technology, Trust Your Supplier provides organizations a trusted exchange of information across an encrypted blockchain environment to minimize risk and fraud throughout the onboarding and life cycle of partnerships.
A single, digital identity for suppliers can be shared with multiple buyers and business networks. This two-tiered supplier profile approach allows suppliers to be discovered by new customers without handing over unlimited access to their data. The Trust Your Supplier cross-industry blockchain network provides clear provenance and a single, shared, tamper-evident ledger. This is ideal for supporting auditing capabilities as it provides an immutable relationship history between parties.
Verified.Me
In our current digital landscape, securely accessing online services has never been more important. With Hyperledger Fabric, SecureKey Technologies established Verified.Me, Canada’s leading digital identity network which helps verify consumers’ digital identity so they can access the services and products they want. With Hyperledger’s support, SecureKey has put user consent at the forefront and in control of when, why and with whom their personal information is being shared. This collaboration is critical to progressing the digital identity landscape in Canada and globally.
Join the conversation about blockchain-based identity technologies and solutions with #HyperledgerIdentity this month on social channels. Also, Hyperledger has an Identity Working Group that is open to all.
Financial fraud isn’t anything new, and the extent of the crime can vary significantly. Forty-seven percent (47%) of US consumers experienced financial identity theft fraud in the past two years—in fact, every 15 seconds a financial fraud incident occurs. COVID-19 has only accelerated the growth of financial fraud. Losses due to identity theft increased by 42% from 2019 to 2020 primarily due to the COVID-19 pandemic, according to a recent study published by the Aite Group.
Today, there are multiple authentication steps in place in financial institutions thanks to the steady increase in cybercrimes. These high-tech frauds take assets from financial institutions and deliver a bit of reputation risk to their public image. Research demonstrates that consumers expect their financial institution to take active steps to mitigate financial risks. Consumers want protection, but they also want a fast and efficient user experience. Too often, each delivery channel is a silo with its own authentication method:
For example,
The call center uses knowledge-based questions
The lobby and drive-up require a driver’s license or other physical forms of identification
Online banking access calls for a username and password plus, often a two-factor authentication.
And consumers want more control over their personal data. In late September 2020, we commissioned a nationally representative survey to over 1,000 adults about their perceptions of MemberPass, Bonifii’s digital credential solution that enables financial institutions to instantly verify financial credentials seamlessly across all consumer contact points in a highly secure and privacy-preserving manner.
There were lots of noteworthy findings:
62% of credit union members said they would sign up for MemberPass if it were available.
56% of respondents who are satisfied with their financial institution would use MemberPass.
67% of consumers would feel more positive toward their financial institution if MemberPass was offered.
50% of consumers would sign up for MemberPass today if a security breach had impacted their account or if they had been identity theft victims.
There is a better way for financial institutions and consumers!
Since its launch in early 2020, MemberPass has been gaining momentum among credit unions and with the members they serve. MemberPass is the financial industry’s first digital credential solution that enables credit unions to instantly verify financial credentials seamlessly across all consumer member contact points. Because MemberPass is built on Hyperledger Indy, credit union members can retain full control of their private personal information. The credential is secure and flexible. It allows the member to reveal only the data necessary for a given transaction. Best of all, it’s impossible to hack or steal.
So far this year, we have seven active MemberPass implementations with another ten more credit unions planning their deployments in the next six months. Our active programs have gotten MemberPass credentials into the hands of about 20,000 members to date.
After we make a program sale, we continue to work closely with our credit union clients. We present each of them with a personalized copy of the MemberPass “Jump Start” playbook. This is a comprehensive toolkit to help the credit union increase the level of member adoption of MemberPass.
The playbook contains product benefits, consumer need identification tools, call center and drive-through workflow models, marketing strategies, incentive programs, and more. Our adoption goal is to get between 5-10% member adoption within six months of the “go live” date.
The demand for decentralized identity among financial institutions is only getting stronger—and, best of all, no one but the consumer owns his or her personal data!
As we continue our pandemic journey that is 2021, more and more people are getting vaccinated against COVID-19. Once vaccinated, people are (finally!) able to do more “in the real world.” However, in some cases such as international travel, there is a need to prove that you have been vaccinated before you can participate. In the past, that proof has been accomplished in the form of the paper World Health Organization Carte Jaune/Yellow Card. But in our 21st century pandemic, a handwritten paper document is not particularly trusted. It’s just too easy to buy or make your own. The sudden, urgent need to be able to prove health information in a safe, privacy-preserving and secure way has brought the spotlight on the concept of verifiable credentials and, for Hyperledger, on the three identity-focused projects in the community, Indy (a distributed ledger for identity), Aries (data exchange protocols and implementations of agents for people, organizations and things), and Ursa (a cryptographic library underlying Indy and Aries).
While people understand that paper credentials are insufficient and that a trusted digital solution is needed, they don’t understand why verifiable credentials, or more generally, identity, works extremely well with distributed ledger technology (DLT)—a distributed database spread across multiple nodes, of which blockchain is an example. To be clear from the start, it is not to put the credentials on a public ledger so everyone can see them! We’ll reiterate that a lot in this post. No private data ever goes on the blockchain!!!
To understand why DLT is useful for identity, we need to go back to the basics—paper credentials, how that model has worked for 1000s of years, and how the use of DLTs with verifiable credentials allows us to transition the great parts—security and privacy—of that model to the digital age.
Since as far back as 450BC, people have used paper credentials to enable trusted identity. Legend has it that King Artixerxes of the Persian Empire signed and gave Nehemiah a paper “safe transit” authorization that he used in travels across the empire. People have been using such documents ever since. In technical terms, a credential is an attestation of qualification, competence, or authority issued to an entity (e.g., an individual or organization) by a third party with a relevant or de facto authority or assumed competence to do so. Examples of credentials issued to people include a driver’s license, a passport, an academic degree, proof-of-vaccination and so on. Credentials are also issued to companies, such as business registrations, building permits, and even health inspection certifications.
A typical paper credential, say a driver’s license, is issued by a government authority (an issuer) after you prove to them who you are (usually in person using your passport or birth certificate) and that you are qualified to drive. You then hold this credential (usually in your wallet) and can use it elsewhere whenever you want—for example, to rent a car, to open a bank account or in a bar to show that you are old enough to drink. When you do that, you’re proving (or presenting) the credential to the verifier. The verifier inspects the physical document to decide if it is valid for the business purpose at hand. Note that in verifying the paper credential, the verifier does not call the issuer of the document. The transaction is only between the holder and the verifier. Further, it is the holder’s choice whether they want to share the piece of paper. If they want, they can keep it to themselves.
Verification in the paper credential model (ideally) proves:
Who issued the credential.
That the credential was issued to the entity presenting it.
That the claims have not been altered.
The caveat “ideally” is included because of the real possibility of forgery in the use of paper credentials. Back to our “proof-of-vaccination” problem.
Let’s see how the good parts of the paper credential model are retained in the verifiable credentials model. With verifiable credentials:
An authority decides you are eligible to receive a credential and issues you one.
You hold your credential in your (digital) wallet—it does not go on the distributed ledger!
At some point, a verifier asks you to prove the claims from one or more credentials.
If you decide to share your data with the verifier, you provide a verifiable presentation to the verifier, proving the same three things as with the paper credentials.
Plus: You may be able to prove one more thing—that the issued credentials have not been revoked.
As we’ll see, verifiable credentials and presentations are not simple documents that anyone can create. They are cryptographically constructed so that a presentation of the claims within a credential proves four attributes:
Who issued the credential–their identifier is part of the credential and they signed the credential.
Who holds the credential–there is a cryptographic binding to the prover.
The claims have not been altered–they were signed at the time of issuance.
The credential has not been revoked.
Unlike a paper credential, those four attributes are evaluated not based on the judgment and expertise of the person looking at the credential, but rather by machine using cryptographic algorithms that are extremely difficult to forge. Like the paper credential, the verifier does not go back to the issuer to ask about the credential being presented. Only the prover and verifier, the participants in the interaction, need to know about the presentation. So where do the prover and verifier get the information they need for their transaction? We’re just getting to that…
Compared to the paper credentials model, verifiable credentials are far more secure. When the cryptographic verification succeeds, the verifier can be certain of the validity of the data—those four attributes stemming from verifying the presentation. They are left only with the same question that paper credentials have—do I trust the issuer enough
So where does the DLT fit in?
Three of the four things that the verifier has to prove (listed above) involves published data from the issuer that has to be available in some trusted, public distributed place, a place that is not controlled by a central authority (hmm…sounds like a DLT!). In Indy and Aries, data published to a DLT is used to verify the credential without having to check with the issuer. In particular:
The verifier has to know who issued the credential based on an identifier and cryptographic signature. From the presentation, it gets an identifier for the issuer, looks it up on a DLT to get a public key associated with the issuer to verify the signature in the presentation. Thus, the identity of the issuer is known.
The verifier has to verify that the claims data has not been altered by verifying a cryptographic signature across the data. Based on an identifier for the type of credential, the verifier gets from a DLT a set of public keys and verifies the signatures. Thus, the verifier knows no one has tampered with the claims data.
The issuer periodically updates a revocation registry on a DLT indicating the credentials that have been revoked. If the holder’s credential is revoked, they are unable to create a proof of non-revocation (yes, that’s a double negative…). If the holder can generate that proof, the verifier can check it. Thus, the verifier knows the credential has not been revoked.
The fourth attribute (the binding of the credential to the holder) in Indy is done using some privacy-preserving cryptographic magic (called a Zero Knowledge Proof) that prevents having a unique identifier for the holder or credential being given to the verifier. Thus, no PII is needed for sharing trusted data.
So why DLT? First, we can get the good parts of paper credentials—private transactions between holders and verifiers and no callback to the issuer. Second, the issuer gets a trusted, open and transparent way to publish the cryptographic material needed for those private holder-verifier transactions. Third, there is no need to have a “Trusted Third Party” participating in the interactions.
And did I mention, no private data goes on the DLT!!!
Hyperledger Indy, Aries and Ursa are enabling this approach to “self-sovereign identity” in a big way, bringing about a new layer of trust on the Internet that will let us preserve our privacy and give us control over our identity and data—where it belongs. There is a lot to learn. If you’re curious, a great place to start is this Linux Foundation edX course.
On Tuesday, the Good Health Pass Collaborative (GHPC) launched. This initiative is intended to define, in the context of test results and vaccination records for opening up borders for travel and commerce, a high bar for implementations of identity and credentialing systems to meet with regards to privacy, ethics and portability. They will also work with the implementers of such systems to converge towards common standards and governance.
A set of Linux Foundation organizations – TrustOverIP, Hyperledger, Linux Foundation Public Health, and its Covid Credentials Initiative – have engaged as supporting organizations and were part of the announcement. We did this based on very encouraging signs during formation discussions that GHPC would not only help bring many of the organizations emerging into the self-sovereign identity space into alignment on platforms and standards we have long championed, but would also give us an external reference point for our position on the importance of privacy in the design and implementation of such systems.
Hyperledger has been home to the pioneering digital identity ledger Indy and agent toolkit Aries, which form the basis of so many productionprivacy-preserving digital identity systems and, now, are serving as the basis for many of these emerging health pass solutions. The TrustOverIP Foundation led the formal recognition of the need and role for governance organizations in the digital identity landscape – showing how we can get both optionality and interoperability when we weave global identity and credentialing systems together in a decentralized way.
The Covid Credentials Initiative, starting way back in March 2020, recognized the potential for credentials of all sorts in the fight against this and future pandemics, and have pulled together an amazing community of technologists and entrepreneurs working together on this. Now, as part of Linux Foundation Public Health, we are working to bring together a set of software projects that can implement credential systems and help accelerate adoption of these globally, centered on the needs of public health authorities.
On Thursday’s GHPC webinar, Charlie Walton from Mastercard said GHPC is “in the business of describing what good looks like.” We will be working with GHPC to bring our own communities’ views of not just what good looks like, but how we’re already working together to standardize and implement this work. Furthermore we’ll see if our processes can directly support GHPC’s efforts to harmonize this domain.
We recognize there are quite a few of these initiatives now, reflecting just how broadly this issue is felt across society. We can play – we must play – a key role in channeling all this market activity and good-faith sharing of expertise into applications directly in people’s hands, so we can get back to travel and re-opening workplaces and schools in a safe and equitable way. Our key levers to move the world are open source software and open public engagement, and we will double-down on those tools to have a unique and substantive impact.
Look for more on this soon within our communities. We’re incredibly excited to be a part of this global effort.