Okay let’s continue the experiment of thinking out loud about putting “identity” on the “blockchain”. Just to recap, in Part One we identified a specific identity problem that might be solved using shared ledger technology, in this case the problem of KYC for financial services. In Part Two we identified a useful and consistent model for digital identity that seemed powerful enough to encapsulate a solution to the problem. In Part Three we worked out which identity transactions we wanted to store in our shared ledger, and we decided that the history of transactions involving a particular virtual identity could serve a useful function as the reputation of that identity. Today, will move the thought experiment on to actually implementing the shared ledger.
Now without thinking about it for too long, it seems to me that there are three options for implementing the Shared Ledger of Identity Transactions that we intend to use to facilitate reputation-based interactions. Let’s call this the SLIT for short. We could implement the SLIT using conventional database technologies and either construct a centralised database for all financial services participants to share all we could have databases held by financial services participants interoperable through some form of federation, as we discussed in Part One. However, as I will return to the end of this piece, that implementation wouldn’t give us access to the likely source of genuine revolution in this space, which I think is the use of shared ledger applications (otherwise known as “smart contracts”) to deliver radically new products and services. Hence, I think we should dismiss the traditional implementation and look at implementations based on the new generation of shared ledger technologies.
I can see two ways of doing this. First would be to implement the SLIT using any one of a number of Practical Byzantine Fault Tolerant (PBFT) technologies that are out there right now. The other possibility, rather as Blockstack have done, is to implement the SLIT as a virtual ledger and build the applications on top of that, then map the virtual ledger to an actual ledger implementation. I tend to favour this latter approach, for the simple reason that it is not at all obvious to me (with the obvious caveat that I know literally nothing about cryptography) which is the best shared ledger implementation. It could be that implementing the virtual ledger on the Bitcoin blockchain is the best possible way of doing things (as shown in the diagram below). On the other hand, it could be that implementing the virtual ledger on an Ethereum blockchain built specifically for the purpose is the best way forward. On the other hand, it may be that not using a blockchain at all and implementing the virtual ledger on some other PBFT platform is the best way forward. As any of our consultants would say when dealing with this problem for a client, it depends. Until we know what the prioritised requirements, constraints and goals for the system are is not possible to say which is the best solution.
So let’s go down this route. We define the SLIT and agree who has access to the SLIT. We define the financial services passport that we spoke about in Part One as a particular kind of virtual identity with some agreed fields. Now we can see how it might work in practice. I go to my bank to open a bank account. The bank does all of the necessary KYC checks and creates a digital identity. The private key associated with this identity is stored safely in the bank and a copy is downloaded to the bank application on my phone and safely tucked away in tamper-resistant memory (inside the SIM card or the secure enclave or wherever). The bank creates a virtual identity using the public key from the digital identity and adds a set of standard fields (name, address and so on and so forth) as required by the regulators. It then adds a digital signature using its own private key. A pointer to this virtual identity along with necessary descriptors is then added to the SLIT.
Now imagine that I go to appoint a new financial adviser. A financial adviser needs to see my financial services passport so I run the bank app my phone and select the option to provide my identity or however the marketeers dress it up. A copy of the ledger entry is sent to the financial adviser. Now he or she (or more likely their app) can go to the SLIT and look at all subsequent entries for that same virtual identity (in particular to see whether it has been revoked or not). The virtual identity looks okay, so now the financial adviser needs to know that the virtual identity belongs to me so his app takes the public key from virtual identity, encrypts a challenge and sends it to my app which decrypts it (because it has the associated private key) and responds. Now the financial adviser can either use that virtual identity or in the more general case use it to generate a financial advice virtual identity which is then stored in the ledger itself.
All of the financial services participants in this ledger can now have access to all of the virtual identities. I think, although I may need to think about this more! Anyway, we now have a problem, an identity model, identity transactions and a ledger to store them in. We’re nearly there.
What is crucial is to implement the virtual ledger using a technology that allows for shared ledger applications, and this is where we’ll continue with the final part of our thought experiment tomorrow.