After this post you’ll know exactly what it means to use blockchain technology for Identity Management.
Our expertise in digital identity technologies has led us to develop a pilot with a major international NGO and to winning awards by The Chivas Venture, the Blockchain Innovation Conference, The Spindle Innovation and more. We recently have been funded with a seven digit figure.
Current identity management systems have privacy and security problems. And blockchain technology may be the solution for them. On this blog we examine what blockchain is, what benefits it brings to identity management, the role of cryptography and zero-knowledge proofs, what Self-Sovereign Identity is, why it’s a terrible idea to put personal data on the blockchain and much more.
Let’s dive in.
What is Blockchain?
Distributed Ledger Technology (DLT), commonly simply called “Blockchain Technology”, refers to the technology behind decentralised databases providing control over the evolution of data between entities through a peer-to-peer network, using consensus algorithms that ensure replication across the nodes of the network.
More simply put:
Imagine a book (or ledger) that anyone could obtain, free of charge, where anything written on its pages would be there forever, and at the same time, would be cross-referenced with the other books to check whether what was written to be valid and true; this is the essence of DLT.
Why was Blockchain created?
Digital assets have a problem. How does one avoid that an asset, such as digital money, is copied and used by several people? That was a problem that always plagued the adoption of digital currency.
Banks allow trust between people exchanging funds. The bank withdraws the funds from person A and assures it’s deposited on B’s account. Both parties trust the bank to perform the operation.
But if one intended to create an ecosystem where there is not a single entity controlling the flow of information, where a user could send money directly to another user without it going through a central entity, this was a problem. How could the people involved in this financial system trust that the money had left A’s account and deposited on B’s? How could it be avoided that this digital money was copied and double (or triple) spent by A?
This problem was solved by the person, or entity, known as Satoshi Nakamoto in 2008.
Why is a Blockchain secure?
What makes blockchain secure is the fact that each block where data is recorded cannot be changed retroactively without the consensus of the majority of the network. Meaning that for a piece of information to be changed, all the blocks created after it would have to be changed and 51% of the network would have to agree on that change. Since blocks are being created every moment, changing those and the blocks preceding it until reaching the one we intended to change, would require enormous computing power.
Satoshi created blockchain to solve the double-spend problem of digital currency and to act as a ledger, a registry, of the transactions of Bitcoin. Each person that transacts Bitcoin acts as a node in the network, registering a transaction on the Bitcoin blockchain. This makes it decentralized, as no central authority is needed and each person in the network can write on the ledger, and allows for consensus in the network without the need of a middle-man. The more people are in the network, the more difficult it is for a majority collusion in order to subvert the veracity of the information on the blockchain.
With a public, immutable, registry, managed by collaboration and collective altruism, this digital currency users could easily verify transactions and be assured that the funds were being transferred only once and not digitally copied infinitely.
A Blockchain is also considered a system with high Byzantine Fault tolerance. A Byzantine Fault is an occurrence on decentralized systems where it may appear, for one user, that the system is working perfectly and, to others, that the system is failing.
How does a Blockchain work?
The units where information are registered, the “pages” of this ledger, are blocks. Each block contains hashed information.
A hash is a function widely used in cryptography. It’s a mathematical algorithm that transforms a piece of information into a string of alphanumeric values: the “hash” or “hash value”. If the same information is introduced in the input, it will always deliver the same hash in the output. If there’s even the slightest change in the input information, the output hash will be widely different (this is known as the avalanche effect). Avoiding any correlation between hashes.
It’s a “one way function” because using the hash value in the output to find what was the information in the input is extremely difficult.
An Example of the hash and how the avalanche effect alters the output with even the slightest change in the input. (Graph Source)
Each block is linked to the next block through a cryptographic hash, and so one. Creating a chain. Thus, the blockchain.
Permissioned or Permissionless Blockchains
Blockchains can be Permissioned or Permissionless.
Permissionless, like the most digital currency blockchains, allow all users to write on the ledger. There’s no permission needed from anyone to become a node on the network.
To become a node on a Permissioned blockchains, one would need authorization from one or several parties. An example of a Permissioned Blockchain is the Sovrin one. Sovrin is governed by a set of Stewards who act as nodes. This is done to preserve the integrity of the information, in this case related to digital identity, that is written on the ledger. Stewards are trusted and vetted by The Sovrin Foundation.
What is Identity Management?
Also known as “identity and access management”, or IAM, identity management comprises all the processes and technologies within an organisation that are used to identify, authenticate and authorize someone to access services or systems in that said organisation or other associated ones.
Examples of this would range from customers and/or employees accessing software or hardware inside a company/enterprise – and the level of access, privileges and restrictions each user has while doing so – or, in a governmental setting, the issuing and verification of birth certificates, national id cards, passports or driver’s licenses (that allow a user/citizen to not only prove his identity but also access services from the government and other organisations).
The problem with current Identity Management Systems
Identity has a problem. If it’s paper-based, such as birth certificates sitting idly in a basement of a town hall, it’s subject to loss, theft of fraud.
A digital identity reduces the level of bureaucracy and increases the speed of processes within organisations by allowing for a greater interoperability between departments and other institutions. But if this digital identity is stored on a centralised server, it becomes a honeypot for hackers. Since 2017 alone, more than 600 million personal details – such as addresses or credit card numbers – have been hacked, leaked or breached from organisations.
Most of the current identity management systems are weak and outdated.
Identities need to be portable and verifiable everywhere, any time, and digitization can enable that. But being digital is not enough. Identities also need to be private and secure.
Several industries suffer the problems of current identity management systems:
- – Government: The lack of interoperability between departments and government levels takes a toll in the form of excess bureaucracy. Which, in turn, increases processes’ times and costs.
- – Healthcare: half of the world’s population does not have access to quality healthcare. The lack of interoperability between actors in the healthcare space (Hospitals, clinics, insurance companies, doctors, pharmacies, etc) leads to inefficient healthcare and delayed care and frustration for patients.
- – Education: It is estimated that two hundred thousand fake academic certificates are sold each year in the USA alone. The difficulty in verifying the authenticity of these credentials leads to hiring of unqualified professionals, brand damage to the universities and the hiring companies.
- – Banking: the need for login details such as passwords decreases the security of banking for users.
- – Businesses in general: the current need to store clients’ and employees’ personal data is a source of liability for companies. A personal data breach may result in huge fines due to GDPR infringement – such as the British Airways case – or simply due to customer trust loss and consequential damage to the organisation’s brand.
Cryptography in Identity Management
Whenever we need to prove something about our identity – either our name, address or passport number – there is a process of authentication. A verifying entity confirms that the data we are claiming about ourselves is true or false. This is usually done through the verification of our identifying documents.
These identity verification and authentication processes make privacy concerns arise. Should a verifying entity requesting me to prove my name with my passport have access to the remaining information contained in my document while they are looking at it to verify that information? Does an entity that request a proof of my age need to know the day and month I was born?
An identity management system that uses Zero-Knowledge Proofs
A Zero-Knowledge Proof is a method of authentication that, through the use of cryptography, allows one entity to prove to another entity that they know a certain information or meet a certain requirement without having to disclose any of the actual information that supports that proof. The entity that verifies the proof has thus “zero knowledge” about the information supporting the proof but is “convinced” of its validity. This is especially useful when and where the prover entity does not trust the verifying entity but still has to prove to them that he knows a specific information.
In an identity management with blockchain scenario, this allows a person to prove that their personal details fulfil certain requirements without revealing the actual details.
For example, one could prove that she is over 21, without showing her exact date of birth.
Zero-Knowledge Proofs are famously illustrated by the “Yao’s Millionaires’ problem”. A scenario formulated by the computer scientist Andrew Yao. Yao discusses two millionaires, Alice and Bob, who do not want to reveal how much money each has but want to know who is the richest.
Blockchain as an Identity Management Solution
In identity management, a distributed ledger (a “blockchain”) enables everyone in the network to have the same source of truth about which credentials are valid and who attested to the validity of the data inside the credential, without revealing the actual data.
The 3 actors in Identity Management with Blockchain: Owners, issuers and verifiers
When talking about leveraging blockchain technology for identity management, it’s important to note that there are three different actors in play: identity owners, identity issuers and identity verifiers.
The identity issuer, a trusted party such as local government, can issue personal credentials for an identity owner (the user). By issuing a credential, the identity issuer attests to the validity of the personal data in that credential (e.g. last name and date of birth). The identity owner can store those credentials in their personal identity wallet and use them later to prove statements about his or her identity to a third party (the verifier).
A Credential is a set of multiple identity attributes and an identity attribute is a piece of information about an identity (a name, an age, a date of birth).
Credentials are issued by second parties whom attest to the validity of the data inside the credential. The usefulness and reliability of a credential fully depends on the reputation/trustworthiness of the issuer.
How Blockchain brings privacy and security to Identity Management
Through the infrastructure of a blockchain, the verifying parties do not need to check the validity of the actual data in the provided proof but can rather use the blockchain to check the validity of the attestation and attesting party (such as the government) from which they can determine whether to validate the proof.
For example, when an identity owner presents a proof of their date-of-birth, rather than actually checking the truth of the date of birth itself, the verifying party will validate the government’s signature who issued and attested to this credential to then decide whether he trusts the government’s assessment about the accuracy of the data.
Hence, the validation of a proof is based on the verifier’s judgement of the reliability of the attestor.
Leveraging blockchain technology, like Tykn‘s digital identity management system does, establishes trust between the parties and guarantees the authenticity of the data and attestations, without actually storing any personal data on the blockchain.
This is crucial as a distributed ledger is immutable, meaning anything that is put on the ledger can never be altered nor deleted, and thus no personal data should ever be put on the ledger.
Identity Management Red Flag: Does personal data go on a Blockchain?
- Putting personal data on the ledger puts the privacy of the users in danger (as it will constantly be subject to hacking and data breaches). It could always be hacked (if not now, probably at some point in the future)
- It violates current privacy regulation (e.g. GDPR; right to be forgotten);
- it is also not efficient as an identity is dynamic (attributes can change over time e.g. house address or number of children).
When working in digital identity and identity management with blockchain, it’s extremely important to always keep in mind that:
No personal data should ever be put on a blockchain.
So if I’m doing Identity Management what exactly goes on the Blockchain?
Only references and the associated attestation of a user’s verified credential are put on the ledger.
Privacy can be ensured through non-correlation principles via pseudonymisation. So, instead of storing actual private information, the only things stored on the ledger (for the purpose of verification) are:
- Public Decentralised Identifiers (Public DIDs) and associated DID Descriptor Objects (DDOs) with verification keys and endpoints.
- DIDs are a new type of unique identifiers for verifying digital identities, and are entirely controlled by the identity owner. DIDs are independent of centralised registries, authorities or identity providers.
- The formal description for the structure of a credential.
- Credential definitions.
- The different (often tangible) proofs of identity or qualification issued by authorities; such as drivers licenses, passports, identification cards, credit cards, etc. Hence, credential definitions are — as the name suggests — merely the definitions of these different credentials to be stored on the ledger.
- Revocation registries.
- An option for issuers to be able to revoke the claim. The revocation registry is what tells the rest of the world how the issuer will publish the revocation information.
- Proofs of consent for data sharing.
- In order to prove consent or reception of data (basically saying the data has been received and checks have been executed on it), these consent receipts (i.e. proofs of consent) let people do so.
Decentralized Identifiers: The next big thing in Identity Management with Blockchain.
DIDs are a new type of unique identifiers for verifying digital identities, and are entirely controlled by the identity owner. DIDs are independent of centralised registries, authorities or identity providers.
According to Phil Windley, Chairman at Sovrin, DIDs should have the following properties:
Decentralized identifiers should be non-reassignable. They should be permanent. Other identifiers, such as IP address or email address, can be reassigned to other entities by whomever is in control. This reduces privacy and security.
Decentralized identifiers should be resolvable. Each DID resolves to a DID Document that states the “public keys, authentication protocols, and service endpoints necessary to initiate trustworthy interactions with the identified entity” (source). Through the DID Document, an entity should understand how to use that DID.
Decentralized identifiers should be cryptographically verifiable. Through the use of cryptographic keys, a DID owner can prove their ownership of the DID. The public key contained in the DID Document can also be used to attest to the authenticity of the issuing authority’s signature associated with a credential.
Decentralized identifiers should be decentralized. Current identity management systems rely on centralized registries. Each of these registries ensures trust. DIDs do not depend on a central authority. Distributed ledger technology ensures trust as it allows everyone to have the same source of truth about the data in the credentials.
A new spec is coming up in W3C where you don’t need to always rely on the central service to resolve DIDs. For use cases where a DID is going to be unique. E.g in pairwise connections or closed groups you can use Peer DIDs. More info on this, here.
Decentralized Identifiers could then increase security, as they eliminate siloed identity management, and increase privacy, as they give the identity owner the opportunity to selectively disclose specific information about himself. Ultimately, they will turn digital identities into Self-Sovereign Identities as they allow each individual to own and control their identity without depending on other parties.
What if I need to change something? Revocation in Identity Management using Blockchain
Next to checking the attesting party, verification of a credential also includes checking the validity of the attestation itself. The validity of the attestation, meaning the accuracy and can be validated through a so called revocation registry.
The registry contains the status of each credential, whether it has been revoked (deleted or updated) and hence whether this specific credential is still valid.
In other words, the ledger enables everyone in the network to have the same source of truth about which credentials are still valid and who attested to the validity of the data inside the credential, without revealing the actual data.
>“This is my drivers licence”
>> “Says who?”
>> “Who are they and do I know I can trust them?”
>> “Do they still agree/attest to this or have they changed their judgement?”
>“Yes they have not revoked their attestation up to now”
Revocation means deleting or updating a credential. The possibility for an issuer to revoke a credential is crucial to an identity infrastructure for the main reason that identities are dynamic.
Attributes can change over time e.g. house address or number of children, and some credentials should have a expiry date for example a passport or drivers licence. The fact is, however, that in order to ensure trustworthiness of the system and eliminate the possibility to defraud, credentials are immutable.
After issuing, no one (not even the issuer) can change the information inside the credential. Hence, when attributes change, a new credential needs to be issued and the old one needs to be announced invalid. Thus, at each proof the users needs to proof that the credentials used in the proof are still valid. The revocation registry allows him to prove this without contacting the issuing party.
For example, the Government issues a credential to you, that you have 3 children. A month later your family is blessed with a 4th child. Now, the Government will mark the previous credential as invalid (stating that you have 3 children) and will issue a new credential stating that you have 4 children.
The revocation registry is a complex mathematical concept. One that we dive deeply on this blog, written by Katja Bouman, about how the revocation registry works.
How to prevent identity fraud and identity theft if I’m doing Identity Management with Blockchain
Through identity management with blockchain technology, each user stores their digital identity credentials on a digital identity wallet on his devices (like his mobile phone). Which begs the question: what if his phone is lost or stolen?
According to Sovrin, there are two steps to be taken.
The first one is to revoke the device’s authorization to use credentials. Digital Identity credentials are only valid if used from a device that was authorized to do so. If a user’s phone is lost or stolen, that user could use another authorized device, like his laptop, to write on the blockchain that his mobile phone’s authorization is now revoked.
This would take immediate effect and stop anyone from using the digital identity credentials on the phone. The thief would not be able to impersonate the user even if he has her passwords, biometrics or phone because the blockchain, immutable and secure, would contain a revocation registry for the phone.
Revocation of the device’s authorization impedes the thief to impersonate the user to create new relationships. The second step impedes the thief to explore the existing relationships between the device and other people or organisations. The second step thus is to revoke the existing relationship keys (pairwise connections where each of them has a unique key).
These two steps stop an identity thief to use digital identity credentials to access new services or explore relationships with existing ones. While conveniently letting the user still use his credentials on another device.
In many current cases, if users wished to cancel a stolen identity card, they would have to physically go to the municipality or governmental department, cancel that card and make a new one from scratch. Which would take time and still would not impede an identity thief from using your data. In the case of a stolen credit card, users will call the bank (which still takes considerable time) and won’t be able to use the card until a new one is issued and sent to him.
Sovrin have published a pdf with a thorough explanation on the technical aspects of device loss of theft that we recommend.
Models of Digital Identity Management
The first model of digital identity management was a siloed one. Each organisation issues a digital identity credential to a user to allow him to access its services. Each user needs a new digital identity credential for every new organisation he engages with. According to Elizabeth M. Renieris (Former Global Policy Counsel at Evernym) this provides a “poor overall user experience”. Just remember all the websites you had to register and create new passwords and login details for.
The second model of digital identity management is called the “Federated” one. Because of the poor user experience of the first model, third parties began issuing digital identity credentials that allow users to login to services and other websites. The best examples of this are “Login with facebook” and “Login with Google” functionalities. Companies “outsourced” their identity management to major corporations who have an economic interest in ammassing such large databases of personal data. This, of course, raises privacy and security concerns.
Facebook, Google and others became the middlemen of trust.
The emergence of Blockchain technology is what allowed the third model of identity management: Self-Sovereign Identity.
Self-Sovereign Identity: What Blockchain will unlock for Identity Management
By leveraging blockchain technology for identity management, Self-Sovereign Identities may become a reality. A Self-Sovereign Identity is an identity you own. It’s yours. Only you hold it, on your own personal digital identity wallet, and only you decide who gets to “see” it and what of it they get to “see”.
This avoids the honeypot problem. There are no centralised storage of digital identity that may be subject to breaches. Meaning that for hackers to steal 50 million digital identity records they would have to hack those 50 million people individually. Considerably more difficult.
Characteristics of Self-Sovereign Identity:
- – User-centric. Each user owns his own data and does not rely on a central entity to prove claims about himself
- – Consent and Control. Each user has full control and consent on what personal information he his sharing and with whom.
- – Interoperability. Self-Sovereign Identity uses a common identity metasystem. This allows users to verify their identity across multiple platforms and locations (that use the same metasystem).
A Self-Sovereign Identity is thus portable, private and secure.
The Benefits of Self-Sovereign Identities
A digital identity management system where organisations store the minimum necessary personal data of their users means less personal data management and less bureaucracy. Reducing data management costs and increasing the efficiency of identification processes. All while putting people’s privacy and security first.
According to Darrell O’Donnell, a digital identity expert, companies are realising the major liability that is storing personal data of customers (or employees). Every breach, loss or theft of personal data may turn into significant lawsuits and fines. Which may mean that, in the near future, companies will also start working their way into Self-Sovereign Identity solutions.
Identity management with blockchain is benefiting several industries. Reducing governmental bureaucracy, shaping a more efficient healthcare system, detecting academic fraud, creating a better banking experience, helping to provide a more efficient humanitarian aid distribution system and helping companies avoid personal data breaches and GDPR fines. You can read more about how and why it is a major innovation in banking and healthcare.
Why is Hyperledger Indy the best solution for identity management with blockchain?
The biggest community of people building a Self-Sovereign Identity infrastructure is Hyperledger Indy.
“Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation” (source)
One of its projects – Hyperledger Indy – is a distributed ledger built for the purpose of decentralized identity.
“Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo.” (source)
Although Hyperledger Indy is still quite young with a lot to be discussed and done, we believe it is by far the best infrastructure to study and to start building a Self-Sovereign Identity solution on. Indy has one of the most mature codebase and an engaged community around it, researching, asking questions and working towards the maturity of the ecosystem. Not only are the best people in the identity field working on developing it but also because it’s part of a transparent consortium, a transparent foundation.
The main tool to start using Indy is Indy-SDK. An SDK (Software Development Kit) is a “kit” that brings all-you-need tools in one library.
We do believe Hyperledger Indy still has to overcome two hurdles:
1) Today the solution still relies solely on the Indy-SDK
That can be tricky as it carries a lot of heavy-weight assumptions like the need to use ZeroMQ, which browsers are not compatible with because it requires RAW TCP access to communicate with the node. That usually requires more recent mobile devices to work. Also, being a kind of all-in-one library it carries functionalities not always needed to everyone that uses it.
2) The use of Rust to write the Indy-SDK
According to Daniel Hardman, Technical Ambassador at Hyperledger, the reason to use Rust as the programming language for Indy was because “We needed a language that could cross-compile for many different platforms, and that produced a C-callable API so lots of other languages could benefit from the artifacts it builds; if we didn’t have that, we’d have to write the same low-level crypto and wallet operations multiple times. Rust, Go, and C++ were the only serious candidates, and Rust had the nicest compiler options for cross-platform. Go’s C-callable support is harder to adapt when you are using Go routines. Rust is growing and is very popular with its developers.”
We do agree that Rust is a very optimized programming language. It was a great choice to develop Indy. It compiles into C and can be read by most of the libraries. Rust can be compiled into C callable libraries and can be called by Node.js. But, in our opinion, it doesn’t matter much if it can be called but cannot be read by the great majority of other programmers.
Other languages that can generate C callable libraries – like C# (CoreRT) – are way easier to read and have a bigger community. For us to ramp-up someone new to this space, someone fresh out of University who needs to be onboarded to Sovrin, for example, we have to teach him blockchain, mathematics, cryptography, P2P networking and now also on Rust. The amount of knowledge that needs to be transmitted makes it more difficult to democratize this technology. To make it available for more developers.
Nonetheless, we believe Rust is a promising language.
The graphics on this post were created by Freepik.