Unless you have been hiding under a rock for the last few years you can’t help but have seen the rise of Blockchain based propositions, touted as the certain next big thing. Pretty much regardless of industry or use case, if you have a problem, someone, somewhere, will be able to propose a Blockchain based solution for it.

The domains of Cybersecurity in general and Identity and Access Management in particular are no exception, on a regular basis we see new Blockchain propositions on a monthly or even weekly basis. Are these world changing arrivals or just another fashion accessory?

 

Blockchain basics

Before we go too far, it’s worth stepping back a bit and looking at the (in my opinion) two core aspects of any Blockchain solution, the immutable store (the ledger) and its distributed nature. These two aspects give rise to the more general name of Distributed Ledger Technology or DLT for short.

The ledger is the core storage for the information, be that (crypto)currency transactions, hotel bookings, URIs, whatever. The original design intent of the underlying Bitcoin blockchain was to give full transparency to all transactions and make them time ordered and fixed once entered into the ledger. Of course, this is where the name comes from, a number of transactions are combined into a block which is added to a chain of existing blocks in such a way as to create a strong (cryptographic) signature of all chained blocks.

The distribution is where the complexity is added. The original Bitcoin blockchain was designed to store transactions with no trust requirements. This effectively means many distributed copies of the ledger are required. Truth is determined by majority vote, and all ledgers are kept up to date through a consistency mechanism. Now, if this consistency mechanism were ‘trivial’ it would be possible to subvert truth by creating 51% vote in favour of your desired outcome. This is where proof of work comes into play. The cost of consistency is kept high requiring significant power and computing resource making the effort required to subvert the truth impossibly high.

 

How does all of this play into identity?

IAM covers many different aspects, but if we restrict our thoughts to core identity provider functionality (the authentication of a ‘user’ and the assertion of claims relating to that user) then at first glance a distributed immutable store might feel like a good fit. However, security, privacy, and the fact that identity claims change over time challenge this first pass view.

Underlying identity data should be private by default, this means the core claim information needs to be outside the ledger. Of course, we can simply ‘hash’ the claims and store those along with a pointer to the core claims themselves on chain or as part of a smart contract. This plays well into the growing proposition of Self Sovereign Identity (SSI) where the user ‘holds’ the claims and releases them as required. However, claims are not immutable, they change over time so we need some kind of ‘revocation’ mechanism, and claims on their own are worthless, they need provenance – somehow that claim needs to be vouched for by someone the ‘relying party’ would trust.

This problem set is well understood and a number of organisations, for example Sovrin and uPort, have provided solutions that utilise Blockchains as a core part of their platforms. But in all cases the consistent theme is the mandate to keep claim data outside the public Blockchain. Holistically, Identity can be reduced to a unique ‘number’ attached to a set of (verified) claims.

The second challenge we face with identity is the provenance of the claims. Making a claim is easy, but between two potentially ‘anonymous’ entities that claim is worthless unless there is some additional reason to believe it to be true. This comes in the form of a verification or validation provided by someone or something. For low value claims a social or distributed validation might be sufficient, but for high value use cases a strong level of assurance will be needed, and this requires a trusted party in some form. As you can see, even though we can democratise the ledger through a distribution process, trusted entities are still required to validate claims for some use cases.

 

Are we nearly there yet?

Claims are a fundamental part of identity, and a public Blockchain is no place for such raw data. Those claims need to be backed by a trusted entity to have value and one of the main DLT propositions is decentralisation and removal of trust.

Here at Ubisecure we are already working with DL technology and companies to understand really where the value lies and how that benefits the identity ecosystem. We are readying some interesting pilots, but more on that later. Despite the current hype DLT is not a solution to every problem, there are some great, proven, viable use cases for DLT, for example un-subvertable directories and transaction recording, and these use cases can certainly have a strong role to play as part of the infrastructure of an identity system, but “Blockchain Identity” still feels like a misrepresentation to me.