Category: Shared Ledger

Putting “identity” on the “blockchain”. Part 4: Create a ledger of transactions

9th June 2016by Consult Hyperion

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.

Putting “identity” on the “blockchain”. Part 3: Define the transactions

8th June 2016by Consult Hyperion1 Comment

Now onto part three of our week of thinking out loud about putting identity on the blockchain. In part one we found a problem that could be solved using some kind of identity infrastructure. In part two we came up with a model of digital identity that we could use to explore a potential solution to this problem. Now, we are going to think about how that model could connect with some kind of shared ledger in general and with a blockchain or, indeed, the blockchain.

Our starting point is to observe, as my colleague StevePannifer said in his presentation at the Cloud Identity Summit in New Orleans this week, a ledger is a record of transactions. Therefore, we must think about the identity transactions implied by the model that we looked at in part two before we start to think about how to store them in a shared ledger. We start by observing that identity transactions are the “CRUD” (that is the Creation, Reading, Updating and Deleting) of identities. Since our model includes three kinds of identities it admits the possibility of three distinct sets of CRUD transactions that might be stored in the shared ledger as shown in the picture below.

The first category relates to the mundane identity CRUD of people, things and organisations. We could take some physical characteristic of these such as a fingerprint, a photograph or a serial number and store these in a shared ledger. This may be a good thing to do, but my first thought about this is that actually we probably want to avoid storing such things in the ledger or at the very minimum storing them in unencrypted form. I have to spend some time thinking this through, but it’s not immediately obvious to me that storing the binding between the digital identity and the mundane identity on the ledger moves us forwards.

The second category relates to the digital identity CRUD. Remember from part two that I am imagining the digital identity as being, essentially, a key pair. We need to store the private key somewhere safe and provide an authentication mechanism so that control over the digital identity can be asserted. Then we need to provide the public key for a variety of uses. Now, a key pair sounds very much like a wallet on a block chain and it is certainly a plausible hypothesis that this could be an implementation of digital identity. However it suffers from the same general category of problem as does cryptocurrency, which is the problem of the storage and protection of the private key. Either you have to look after the private key yourself, which is a degree of responsibility that I for one am most unwilling to accept, or you have to trust somebody else to look after the private key for you (e.g. your bank).

In practice, this would mean that the key pair is held by some third-party and while the idea of having sovereign control of your digital identity in some sort of blockchain is an appealing prospect if you are a 20-year-old computer science major MIT, I remain unconvinced that is a mass-market solution especially in developing countries. Here, I feel that the example of M-PESA (as we were discussing on Twitter yesterday) is illustrative. M-PESA, which was launched remember by a telco not by a bank, stores cryptographic keys in the tamper-resistant SIM in a mobile phone and this strikes me as being the plausible mass-market solution. In an M-PESA-like system, the SIM generates the key pair and gives up the public key but the private key is never disclosed. Uunfortunately this means that if you lose your SIM you may have messages that you can no longer read so we need a more sophisticated mechanism for a workable mass-market infrastructure!

The third category relates to the virtual identity CRUD. Remember in the model that I sketched out in part two, I made the assumption that all transactions are between virtual identities. Now the transactions associated with a virtual identity, if they were to be stored in a shared ledger, would then provide a record of that virtual identity’s activities. Those virtual identities need not identify the binding between the digital identity and the mundane identity. So, I could have a digital identity that I use for work and one for home and one for play. I use my play identity to obtain an adult identity from some grown-up website and that identity might well contain attributes that it has obtained from other credentials (that I am over 18, for example) but not my name.

Then the history of that virtual identity is in effect a kind of reputation. If you ask me for my reputation on some sharing economy platform, I can point you to a entry in the shared ledger. This gives you a public key. You can do two things with this key right away. First of all, you can use it to encrypt a challenge for me (because in order to answer the challenge I must have control over the corresponding private key). Secondly, you can look through the ledger to find transactions associated with that public key (to find out, for example, when the virtual identity was created) and whether is has been deleted.

You can also check the digital signature on the virtual identity to confirm who created it (i.e., was it really Barclays Bank or AirBnB or whoever).

The ability to check the reputation of a counterparty in this way seems to me to one of the fundamental benefits of such an identity infrastructure and central to a functioning online economy.

If I find a seller labelled as John Doe, I really have no interest in discovering their underlying identity: that takes time and effort. If there are positive comments about them from people whose opinion I value then I will do business with John Doe. If there are negative comments, then I won’t. And it won’t matter to me whether John Doe has badge from the local council, the government or some other body’s approval. My decision will be based not on what anyone thinks, but on what everyone thinks.

This comes from an article I wrote for “The Guardian” a fair few years ago (“Reputation not Regulation”, 2nd Nov. 2000, sadly longer online but you can download a PDF here). On this, I don’t think my opinion has changed much. The ideas that I was putting forward back then we constructed to support economic activity with both security and privacy as priorities. If anything, my views about building security and privacy into the identity infrastructure have become more entrenched since then.

Now, in the “old” PKI model, if I presented you with a virtual identity you would have to go to the issuer and check the certificate revocation list (CRL) or access an Online Certificate Status Protocol (OCSP) responder to see if it is still valid. In order to minimise the traffic, the issuers would basically need to issue virtual identities with short expiration dates which would mean people, organisations and devices constantly having to obtain new certificates. Now, this in itself is I think workable. But in the shared ledger version of this story, there is no need to query the issuer because the history of the virtual identity is in the ledger.

In the model we’ve been building up this week, then, reputation can be interpreted as the history of a virtual identity, the complete list of “CRUD” transactions stored in the shared ledger. Does this seem like a reasonable model to proceed? If so, tomorrow I’ll think out loud about how to implement the shared ledger for identity.

Putting “identity” on the “blockchain”. Part 2: Create an identity model

7th June 2016by Consult Hyperion2 Comments

I’m continuing my week of thinking out loud about identity on the blockchain. In Part 1, we came up with a real problem that needs fixing and explored the idea of a financial services passport. In Part 2, we’re going to put forward an identity model that could form part of solution to that real problem. The starting point for the thinking here is that as part of some recent work for a client, at Consult Hyperion needed to create a simple digital identity model to facilitate discussion around the provision of digital identity services to support financial services. In order to do this we revisited three basic concepts of identity infrastructure. These are the mundane identity (the “real world” physical entity that the digital identity is connected to), the digital identity itself and the virtual identities that are used to interact online (all transactions, in this model are between virtual identities).

The reason for this three part model for identity is that it is a fundamental rule of systems analysis, going back to the earliest days of data modelling, that you cannot have many-to-many entity relationships. Since there may be multiple physical entities relating to multiple virtual identities (an obvious example is a company, where a number of people have executive control over a number of virtual identities that are used to transact with other companies, government, regulators and so forth), we introduce digital identity as the linking entity to enable a workable identity management infrastructure.

This part of the model should be familiar. You probably read about it a few years ago in “A Model for Digital Identity” by Neil McEvoy and me in that indispensable tome “Digital Identity Management: Technological, Business and Social Implications“, edited by yours truly. (It’s on pages 95-104, for ready reference.) In that chapter, Neil and I put forward this idea of digital identity as the bridge between mundane and virtual identities for a variety of reasons anchored in the entity-linking structure, one of them being that the use of multiple pseudonymous virtual identities is a great way to move forward past some of the apparent paradoxes of identity and a great way to think about identity in an online world.

Anyway, I wanted to use this model to explore the issue of biometric authentication. This was because Isabelle Moeller from the Biometrics Institute (below centre) had kindly invited me to give at talk on the topic of biometrics and digital identity at their 2016 Asia-Pacific Conference in Sydney and then take part in a panel discussion with Victoria Richardson from APCA (who was unfortunately caught up in other things on the day but the excellent Nick Cliff stood in for her) and Mandy Smith from ANZ (below left). Since the audience would be mainly people with experience and interest in biometrics, I thought (correctly, as it turned out) that a simple of model of digital identity would be needed to anchor my talk and give context to the central part of the presentation, which was about biometrics as a convenience technology when combined with mobile as an authentication platform.

To make that simple model, I chose to map the three identity entities to three different domains where a binding is required (hence three domain digital identity, or “3D-ID”). You can see the three domains and the three bindings in the picture below. In the identification domain we do the complex and expensive binding of the person or organisation or thing to the digital identity. In the authentication domain we bind the digital identity to a person or organisation of thing that is entitled to use it. In the authorisation domain we bind the digital identity to the virtual identities that interact online to execute transactions. For the purposes of simplicity, think about the digital identity as a private-public key pair and think about the virtual identities as public key certificates that take the public key from the digital identity and link it to attributes to form credentials.

So who might be a provider of digital identity, given that the binding of digital identities to mundane identities is complex and expensive? Well, here’s what Neil and I wrote in the book nearly a decade ago:

One could certainly imagine niche identity issuers springing up across both horizontal and vertical sectors (the government, from this perspective, becomes a special case of a niche identity issuer) where economics or other pressures dictate.

An obvious case would be that of banks. Since they are already covered by “know your customer” (KYC) and other legislation, they are perfectly capable of issuing digital IDs that might be widely accepted. These and other digital IDs would then be used to create one or more virtual identities (eg, an employer creating an employee identity), most likely through brand-based businesses using white-label services.

To illustrate what we meant by this, think of the example of a dating site. The dating site needs to know that I am a real person, but it doesn’t need to know who I am. If it knows who I am, then it has a responsibility to look after my identity, which I’m sure it doesn’t want. I don’t want it either, because when the dating site is inevitably hacked I don’t want my identity smeared all over the web. So when I go to create my account at the dating site (in others words, when I go to create my dating virtual identity) I can present my bank virtual identity. The dating site forces an authentication (using, for example, FIDO) and once it gets the positive response it can then take the public key from the bank virtual identity, add attributes that it can attest to (e.g., date joined, name chosen, etc) and sign that with its own private key. This creates a new dating virtual identity at minimal cost. (We’’ return to the point abut correlating public keys across virtual identities when we come back to think more about implementations.) Take it from me, it all works, provided you have somewhere to store the private key. Sound familiar? Well, we’ll talk about digital identity and the blockchain in another post soon.

The focus of my talk was that the arrival of biometrics as a convenience technology in the authentication domain transforms the usefulness of this model in the mass market. There’s a world of difference between creating a new account at the dating site and then being asked to look at your phone (face biometrics are especially popular amongst older people, for example) and being asked to get out a dongle, insert your EMV card, enter your PIN, read a code and then type it into a web page. And, as an aside, one of the most interesting presentations I saw at the event was about he use of the phone and the touch screen to perform continuous background authentication so that when a service provider forces an authentication on the device, the customer may well have to do absolutely nothing at all!

One more thing about the model. On re-reading that chapter (which was first drafted a decade ago), I couldn’t help but notice that Neil and I had already had an inkling that the paths of the Internet of Things and digital identity would cross. We wrote:

People will account for only a fraction of the digital IDs associated with stuff, and a lot of stuff will be interacting with virtual identities: after all, a vending machine dispensing chocolate may not need to know anything about a person, but one dispensing cigarettes certainly does. Since it would be ludicrous (and an open invitation to identity theft) to insist that people present their real identity to a vending machine, it is the attribute (eg, “is_over_18” or something similar) bound into the virtual identity that is the critical element in enabling the transaction.

Rather forward thinking, if you ask me, especially since on my last trip to Frankfurt I discovered that there are cigarette vending machines in the street that require customers to present their actual identity cards (well, someone’s identity card, anyway) in order to purchase!

What the machine should do, of course, is require you to present your “adult identity” (that contains no identifying information and merely testifies that you are over 18) and then force an authentication against that (via Bluetooth or whatever). As we all know, in a commercial transaction of this nature, your “real” identity is your least important attribute.

Putting “identity” on the “blockchain”. Part 1: Find a problem

6th June 2016by Consult Hyperion7 Comments

I have to give a presentation about putting identity on the blockchain, even though no-one seems entirely clear what “identity” means or, for that matter, what “blockchain” means. So I thought I’d try and experiment in thinking out loud this week, using your feedback to try and finish the week with some consistent model of a solution that will solve a known and understood problem. A tall order. But there’s lots of work being done in this area and I’ve been reading some very interesting papers and posts. I think it’s a worthwhile experiment in the week of the Cloud Identity Summit and I’m hoping that colleagues and friends in New Orleans will be coming up with some new ideas in this area too.

OK.

There has been a lot of discussion recently about the idea of using the blockchain to “do something” about identity, so I thought I’d put together a few blog posts with some of our thoughts on the topic, gathered from a few of the different projects that we are involved with. Lots of people seem to think that putting identity on the blockchain is a good thing to. But, as many other people have pointed out, in order to come up with some kind of idea as to what exactly the blockchain is going to do is first necessary to come up with some idea about what the identity problem is and then come up with some more specific ideas about how exactly a blockchain (or, more generally, any other form of shared ledger) might solve them.

The idea for this blog post began when my colleagues were putting together some ideas to present at the Open Identity eXchange (OIX) meeting in London few weeks ago. I thought it might be useful to contribute some of our thoughts around that presentation, in their incomplete form, to structure further discussion around this topic. First, the identity problem. Actually there are lots of different identity problems so I thought I’d choose a specific one I’ve been working with recently. As the chair of the techUK payments group (techUK is the trade association for the British technology industry), I’ve been taking part in the Financial Services Passport Working Group that started discussing the issue a couple of years ago. This is a good example of a very specific identity problem and a community that is looking for solution.

Let me illustrate what the problem is with a personal example. I’ve been a customer of Barclays since 1977 and they know absolutely everything about me and my financial history. My salary has always been paid into the same Barclays current account. My mortgage is currently with Barclays and were I to have any savings they would probably be with Barclays to, since I’m extremely lazy. Now suppose I go to open account with the NatWest. The fact that I’ve had an account with Barclays the 40 odd years will count for absolutely nothing and they will treat me as if I’d just arrived as a refugee. I have to produce some form of identity documentation (which they might well be incapable of verifying: I have literally no idea how the counter staff at NatWest go about checking whether a Romanian passport is real or not) as well have some proof of address, which normally comes down to that well-known high security fundamentally British identification document, a gas bill.

Now suppose I go to get some pensions advice from a financial adviser or look into changing my mortgage to get a better deal or decide to open one of those ridiculous Individual Savings Accounts (ISAs) that the Chancellor of the Exchequer has created so that rich people can salt away tax-free money for their children and thus drive up house prices even further to no general economic benefit to the nation. In any of these cases I would be faced with the necessity to provide my financial identity all over again. So what can be done about this? It’s hardly a new problem.

“An adviser to a new charitable incorporated organisation that spent more than a year trying to open a bank account has blasted Barclays for its onerous demands and disproportionate due diligence.”

Barclays slated after CIO takes a year to open a bank account

Well suppose when you open your first bank account and the bank goes through all of its complex know your customer (KYC), anti-money-laundering (AML), counter-terrorist financing (CTF), politically exposed person (PEP) checking and credit referencing and then decides to give you an account. Suppose at that point the bank gave you some kind of financial passport (put to one side what this actually is or what data it contains or where that data might be stored) that you could use to open accounts at the NatWest, change mortgages, open a savings account or obtain financial advice simply by proving that it is your financial passport. Then it becomes a simple problem of authentication and we have a variety of strong authentication mechanisms available to us (even without some proper National Entitlement Infrastructure as I have long called for). The cost savings to the industry from not having to continually repeat identification procedures would be substantial and the convenience afforded to the consumer notable.

So why doesn’t this happen? Well, that’s a good question. We started to look at it a generation ago and the assumption was, at that time, that we would use public key infrastructure (PKI) to solve the problem. I know, I know, people have been going on about this sort of thing for years (here, for example). So, I open a bank account and the bank generates a key pair. The private key is kept in tamper-resistant hardware (at the bank, so that I can’t lose it) and the public key is used to form a variety of public key certificates (PKCs) or what I prefer to call “virtual identities”. Each of these identities contains a number of different attributes that are attested to by whoever signed the certificate.

Now I wander into the NatWest and present my Barclays virtual identity, perhaps by using my mobile phone or smart card, and all NatWest have to do is to validate that I am rightful owner of the private key associated with the public key in the certificate. They can do this in a variety of ways, but let’s say for sake of argument they send a message to my phone that is encrypted using the public key in my Barclays virtual identity and my Barclays app on the phone demands strong authentication and gets it and reports back. NatWest would also have to check that the public key certificate I’m presenting to them hasn’t been revoked so this means they have to query the Barclays Certificate Revocation List (CRL) in some way either as part of the challenge to the app or in a separate step.

Problem solved.

Or a least it might have been, had anybody ever implemented any of this stuff. Identrust gave it a go in the corporate space, defining a complete set of standards and more importantly the business rules that go around them, but nothing ever happened in the customer space. I did think for a while that, because the cryptography used to support chip and PIN is the same as the cryptography needed to support this kind of PKI, it would be efficient to add something along the lines of the financial passport to the debit cards in widespread use. I have a vague memory of being involved in some discussions around this with one of the UK banks a decade or so ago and as I recall (and my memory may well be imperfect) the reason for not doing it was that debit card production was outsourced to one particular supplier and they had no interest in raising the cost of the cards issued by a couple of pence in order to save the bank a ton of money in the branches or to combat fraud. I shouldn’t think things have changed much by now. And persons of a suspicious nature may well want to believe that banks don’t want to make identification easy and portable because they see it as a way of locking in customers, but I am sure that they would not engage in this kind of behaviour.

So if we’re not going to implement the financial services passport that way then how can we implement it? In the techUK working group that’s been looking at this we were really focusing on a couple of obvious architectures that all simplify down to the centralised architecture and the federated architecture. In the centralised architecture, the banks will all chip in to build a central database somewhere, perhaps run by BACS or some other industry body, and that would hold the details of the identity, the identity verification processes that had been completed and the relevant keys and certificates. So I go into NatWest to open accounts and I authenticate myself to the financial services passport database and Bob’s your uncle. This would have course require some coordination between banks and everybody else, and it would have to be pretty reliable otherwise it would turn into a honeypot for criminals and fraudsters, but it’s a plausible hypothesis.

Another way of doing it would be a federated solution where each bank holds its own database of the financial passports that it has issued and other banks can query that database using the normal protocols of federation in order to gain access to the data under controlled circumstances. I used to think that this would be the best of way of moving forward, decoupling the banks in this way, despite what it meant in terms of having to sort out liability agreements. I remember a survey for VocaLink a couple of years ago in which some two-thirds of respondents said that they saw value in the establishment of that centralised KYC utility, and I was sure they were wrong. There’s no need for a central KYC utility, I thought, when we could have a federated identity linked to verified attributes infrastructure (i.e., a reputation infrastructure).

There would be no need for NatWest to actually store my Barclays financial services passport, they would just need to store a pointer to with the records showing that they had checked. Then if I subsequently get arrested for fraud or Barclays closes my account because I turn out to be associated with money-laundering, we need some mechanism for informing all the other people who are depending on that passport that it is no longer but I’m sure it’s not beyond the wit of humanity to come up with some sort of semantic federation that could take care of this.

In recent times, however, a new possibility has wandered into the discussion. Yes, the blockchain. Well, a blockchain. Or to be more precise, some form of Shared Ledger Technology (SLT).

What if we could use shared ledger technology to build this record of financial services passports but but in such a way that no institution owned it, that it had no central system to go down, that it could resist intrusion or attempts at fraud from compromised members of the network, and that it could provide a platform for new products and services that we can’t really imagine at the moment? Personally, I think the shared ledger may well a plausible solution to this problem and having chaired a discussion on identity and personal security as well as a superb panel on identity at Consenus 2016 in New York I’ve been thinking harder about what shared ledger technology could do for organisations in this field. If we take our layer-based model (the “consensus computer” and the applications that we are going to run on it) and begin to think what kinds of identity-related content might be useful, I think we can get somewhere.

Let’s start building the models that we need to think this stuff through clearly. I think we should start with our model of the Shared Ledger that we are going to use to store “identity”. I think Consult Hyperion’s “4×4” model works very well, so we’ll use that.

So in this emerging paradigm, our thought processes then drift on toward the content of this ledger. I saw some interesting demos at Consensus. Deloitte and others had started to build blockchains with defined content assets and these were interesting. But let’s say for sake of argument that a ledger is a record of transactions. The ledger isn’t simply a write-only file containing copies of driving licences and passports and whatever else, it’s a record of transactions that link entities identified at the communications layer with a variety of identity attributes through transactions, developing a reputation associated with that identity. This, I think, is the kind of architecture that Cambridge Blockchain explained to me when I bumped in them last year and it seems a reasonable starting point, congruent with our ideas about the kinds of transactions that might be entered into a shared ledger.

Thus, a blockchain can act as a provenance protocol for data across disparate semi-trusting organizations.

From Will Provenance Be the Blockchain’s Break Out Use Case in 2016? – CoinDesk

We have to be careful with what we are putting in the Content layer, naturally. We don’t want to turn the shared ledger into a resource for despots and confidence tricksters. Hence it is reasonable to ask whether anyone should be able to look at my financial services passport or whether it should be encrypted in some way so that only “authorised” entities can decrypt it. My first thought is that we may want to go for something like this, which is why I prefer to call the Content Layer of our model translucent rather than transparent.

A distributed and irreversible system for trust management, which stores personal data, could offer a hotbed for doxing and identity theft – and even undermine an individual’s right to be forgotten.

From What Airbnb’s blockchain proposal means for privacy

Indeed it could, which is why it should not store personal data in the clear. So, to end this problem statement of our thought experiment, let’s recap: what we will be storing in the shared ledger is not identity itself but some kind of identity transaction and when you come and present your financial services passport to a bank, you will do it by proving that you have control of the private key that corresponds with the public key that is linked to the relevant identity transactions (e.g., Barclays KYCd Dave Birch).

Reasonable starting point? Your thoughts?