Meet Cordentity!
Cordentity is an identity Corda application (CorDapp) that brings Self Sovereign Identity (SSI) capabilities to other CorDapps. In other words, Cordentity = Corda + Identity.
And we’re happy to share that Cordentity is now available as an open-sourced Hyperledger Labs Project.
We developed Cordentity to take advantage of SSI capabilities enabled by Hyperledger Indy. As there’s no official definition of Self Sovereign Identity, it’s important to clarify that Hyperledger Indy is based on two important concepts: DIDs (Decentralized Identifiers) and ABCs (Attribute Based Credentials aka Verifiable Claims).
Self Sovereign, in this context, means that the Credentials (digitally signed Claims, or set of attributes) are stored directly by identity owner and only shared on a need-to-know basis. These credentials are cryptographically signed by well known entities (e.g. Passport Office, Hospital, University, Bank, etc) who are authoritative actors in their domain. This way we can combine existing authorities and “trusted sources” (that have public DID’s) with a very flexible, scalable and secure way to share information.
One can use this powerful combination of technologies to solve many challenges related to digital identity management and verification of credentials in a privacy-preserving way. This approach is also GDPR compliant and enables many applications that have to deal with Personally Identifiable Information (PII) that otherwise would be very difficult to implement.
In fact, if we look at the many use-cases being implemented by the blockchain community, most of them deal with identity and credentialing. Of course, at a very basic level, public/private key combinations that are used to sign and verify transactions define identity, or at least “ownership” of a digital asset. However, as soon as we try to add additional attributes — age, nationality, banking relationship, insurance information and so on, the need arises for a solution that will give us a privacy preserving and scalable way to handle this sensitive data. Storing this data on immutable ledgers is not a viable option.
In other words, to realise the full power of decentralization technology and smart contracts we should combine the functionality of SSI and Verifiable Claims with DLT and blockchain based systems.
Ok, you might say, so far so good, but why Corda?
And here we have to consider how majority of blockchain platforms work and their design assumptions. In fact, most of the platforms out there were inspired by Bitcoin’s design — a closed loop system that works as hard as possible to make sure that its current state (in case of Bitcoin balances or UTXOs) can only be achieved by sequentially applying all the documented transactions that happened since the genesis block. I say “closed loop”, to highlight the fact that the key feature of blockchain systems — trustless, decentralized, distributed record of events is only true, especially the trustless part, if it’s the native assets (e.g. Bitcoin or Ether, etc) that are being tracked. Anything else that is being recorded onto blockchain — hashes to external documents, events, etc are just records that are anchored in history but were not validated by the protocol.
It’s clear that most Enterprise use-cases need a very different system, one that would on one hand allow partners to synchronize arbitrary processes and facilitate data exchange without a central, trusted intermediary and, on the other hand, do it confidentially and selectivity.
It’s easy to see that a “closed loop” system will not suffice as we have to make it easy to create arbitrary “business protocols” that would, necessarily, enable native (i.e. secure) consensus over interactions with third party systems and oracles.
Corda is such a technology.
As we started exploring the benefits of Verifiable Claims, as described above, we quickly realized that exchange of Claims (signed digital attestations that carry a set of attributes) and Proofs (anonymized combinations of verifiable digital attestations) to open a bank account, for example, or receive medical treatment, rent a vehicle, etc naturally fit well with the idea of Corda Flows — the programmatic way to complete a transaction among a selected set of participants.
In this paradigm, Claims/Proofs/Identity are inputs to a business process (think of check boxes in a rules book or a checklist) that is governed by the distributed smart contracts Corda engine. As transactions are being kicked-off, Flows allow us to collect signatures and data for verification from all related Corda Apps (code that implements business logic or a functionality on a Corda Node), including the ones that interact with external identity/verifiable claims infrastructure.
For us it was a clear pattern and so we created a CordApp (our Cordentity) to make it easier to build business protocol apps that rely on this powerful combination of technologies.
The Power of Partnerships and Open Source
Naturally, we were not the only ones thinking about this and as we talked to our partners at R3 we’ve discovered the other similar efforts. We’ve received a ton of good feedback and patient advice from Corda’s technical team and were encouraged to contribute our work to the community.
Coincidentally, R3 was just about to launch their Market Place and so we were able to be one of the launch partners at the debut of the Marketplace Portal. This created additional visibility and a stream of interest in the solution that convinced us that we should push it further.
After numerous discussions with the Corda team, we were convinced that exposing our work to Hyperledger community (that works on a number of DLT/Blockchain related technologies and building blocks, including Indy) was the right way to go.
With just a little effort, we were able to get accepted in Hyperledger Labs incubator area for new projects and now work with the extended community to get additional contributors and ensure adoption.
Latest Hyperledger Global Forum in Basel showed that there are many projects in the community that start to adopt Hyperledger Indy technology for production use-cases and that our contribution was timely. After all, we are only going to be successful if we, as a community, make it easy to create systems that solve business problems and get deployed in production. It’s difficult to get there unless we all work together and build on each other lessons learned and best-of-breed enabling technology.