In the first part of this series, we introduced the idea that traditional PKI-based digital identity solutions can potentially benefit from blockchain technology. We also touched on how blockchain is effectively a database tech that has properties which make it excellent for ensuring that data cannot be deleted or manipulated over time. Though we mentioned that one of the drawbacks of blockchain technology was related to the time it took for changes or transactions to be made, there is significant effort being made in this space, so we’ll ignore this potential downside, going forward.
Achieving Privacy with SSI
For this next part of the series, we’ll touch on the relatively new idea of self-sovereign identity, or SSI. The principles behind SSI are focused around privacy and data control being in the hands of the user, rather than there being significant reliance on third parties that effectively learn something about activities unrelated to them due to their part in providing certain data attributes about the user. One way of putting the control in the user’s hands is by actually giving them their data attributes in a way that enables them to share these whenever they want, without relying on the issuer of that data. For example, I need to prove my address to a bank in order to open an account there. I have two options: I either request a letter from my rental agency confirming my address, or I send a copy of my rental agreement to the bank. In the first option, I must rely on the rental agency for the letter, in the second option, I end up sending the bank far more information than is necessary.
With SSI, I might have a data attribute store, which contains a range of attributes such as my address, what insurances I have, my degree diploma, my income, etc. This might all be stored on my phone in a wallet, or in a cloud storage solution. If the bank needs to know my address, I simply send them that specific attribute from my store. Now, the problem is how can the bank trust that attribute is true? This is where we require “verified attributes”. These are attributes that have effectively been digitally signed as true by the issuer. When the bank receives the attribute, they can quickly query whether this attribute has been verified by a trusted and relevant source. What SSI looks to avoid is the bank engaging with the issuer, in this case the rental agency, as this means we’re back to relying on the rental agency. The rental agency, in turn, will learn we are engaging with this particular bank, most likely to open an account, and effectively learn information about us that isn’t theirs to know.
Blockchain's Part in SSI
Where blockchain can be used here is in storing the verified status of attributes. Effectively, this would be acting in a similar way to an Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) that is usually operated by a Validation Authority, part of the offering from a CA/Trust Service Provider. If we can utilise blockchain for this use case, we can limit the reliance on the Trust Service Provider. In doing this, we’d likely open the door for the need for another anchor of trust or set of audit processes responsible for the blockchain and its utilisation, but this is another topic. The issuer of the attribute would “sign” a hash of it, claiming its validity, this validation signature being sent to a blockchain. The receiver of the attribute, the bank, would receive the attribute with a “signature” stating this attribute is correct, and the bank would then be able to quickly check if is this signature/attribute combination is valid by checking the relevant blockchain.
In this particular instance, blockchain effectively replaces the OCSP and reduces reliance on a central party, the Certificate Authority (CA). The data is stored securely across nodes, in a way that it can’t be modified, and is protected in the long term. We are back to reducing the reliance on CAs by using blockchains to store the data that provides trust to a digital identity service. PKI-based digital identity services, those that offer the ability to create legally binding digital signatures, rely heavily on trust, and many believe that blockchains can be a key player in creating trust in a service. What might be more accurate, is to say that blockchains have the ability to maintain trust in a service. This is often how they are used. For example, in Estonia, KSI Blockchain is used to provide integrity to transactions that take place on the X-Road, the e-Government data exchange platform. No data is stored on the blockchain, only hashes, but this is sufficient to ensure that data related to transactions can never be changed without being recognised.
It Always Comes Back to Trust
Trust is integral to the kinds of digital identity services that are aimed at government or heavily regulated industries, such as banking. In some descriptions of SSI, blockchain is a vital component related to the verifiability of attributes being shared. In a way, this is similar to how blockchain may maintain trust related to who individuals are by storing public keys and certificates in decentralised PKI. In both of these cases, blockchain is simply being used as a database; a genuine use-case for the technology, but, unfortunately, with blockchain, we often find ourselves asking, what is the problem that needs to be solved. In both of these cases, the provider of trust is the Certificate Authority, responsible for the verification of the individual’s identity and subsequent tying of that identity to a public key, and the provider of the OCSP service. CAs effectively trade in trust and are heavily audited because of it.
CAs may not be perfect, but the use of blockchains will not replace the need for CAs. There is nothing to say blockchains won’t be used by CAs, maybe even for the use cases above, but so far, the existing ways of working have been effective, and blockchain alone does not a digital identity service make.
In the final part of the series, I’ll conclude on the age-old question of what problem needs to be solved by blockchain. I will also dig a little bit deeper into whether the use cases I’ve mentioned are really offering value we can’t find elsewhere.
Written by Maximiliaan van de Poll
Digital Identity Product Manager