Examining the Relevance of Distributed Ledgers to Identity
Blockchains, or more generally Distributed Ledger Technologies (DLTs), are hot. Let's get that out of the way. Part of that hotness is people arguing for DLTs application beyond cryptocurrencies where they first became popular. Indeed, DLTs are being imagined for every use case where more than 2 people interact online - including their application to identity. But are the features that DLTs provide relevant to identity? Are the tradeoffs worth the advantages relative to existing identity models and architectures? This post is the first of a two part exploration of that question. Part 1 attempts to tease out what are the arguably unique capabilities of DLTs, and so determine a set of criteria for their applicability. Part 2 will explore whether identity applications meet those criteria - and so whether identity is a relevant use case for DLTs.
DLTs are often portrayed as a 'trust engine', 'trust machine' or 'manufacturing trust'. The implication is that DLTs create trust where there was none before. Ironically, DLTs are also often characterized as 'trustless' - implying that the total trust in a system (whatever that means) has decreased. Rather than increasing or decreasing trust - DLTs move trust around, redistributing it away from centralized actors to a more equitable and distributed model. For example, where traditional currencies rely on some central bank standing behind that currency, Bitcoin does away with that role. Those who accept Bitcoin for payment do so not because they trust a central bank blessing each coin or bill, but rather because they trust the network of miners that validate transactions (and implicitly, the Bitcoin protocol and cryptography) .
So what do I mean by trust?
Trust, (noun), The act of choosing to believe that some other actor will, (or will not) perform certain operations even though no technical mechanisms force (or prevent) them performing those operations.
So, you trust someone if they are able to act (either of by commission or omission) in a way that might harm you, but you nevertheless choose to believe that they won't do so.
There are implications of the above definition, including:
For two parties with no direct relationship contemplating engaging in some form of transaction - the historical model to overcome the lack of direct trust (ie such that they are unwilling to believe the other won't act to do them harm) is to introduce an intermediary into the mix. Instead of the two parties having to take it on faith that the other will perform (or not) certain operations, they instead take it on faith that the intermediary will do so. The trust placed in the intermediary is in the same sense as above, ie the intermediary could act to harm you, but you choose to believe they won't. Because you believe the intermediary will do what they claim to do, you need not assume the other actor will behave in particular ways because if they do not, the intermediary will either stop them or protect you from any consequent harm.
In this view, trust is a leap of faith - a 'willing suspension of belief' to paraphrase a literary trope. Despite believing that some other actor could harm us, we suspend that belief in order to proceed. With this sense of trust, it's hard to imagine any business choosing to trust another if they could avoid doing so. Businesses generally favor certainty over faith. As Benito Mussolini is reported to have said - 'It's good to trust others but, not to do so is much better.'
The value of DLTs is their potential for deprecating the involvement of an intermediary (and the need to trust that intermediary), and yet still allowing otherwise untrusting participants in some network to be willing to engage in transactions.
A distributed ledger is a database for recording the transactions of assets in which the state of the various assets are recorded in multiple places at the same time - these copies distributed across multiple servers, institutions or locales.
In the absence of a single authority that unilaterally determines the state of the ledger, there must necessarily be an alternative mechanism by which the collective network can do so. Consensus is how nodes (some if not all) in the network come to an agreement on the state of a distributed ledger. The specifics of how consensus is established, who is authorized to contribute, and how conflicts are resolved etc., are the characteristics that distinguish different DLT algorithms.
In the case of Bitcoin's blockchain, the so-called 'proof of work' mechanism is used for establishing consensus, or more accurately, in ensuring that consensus isn't corrupted. For Bitcoin and other distributed consensus networks, the fundamental requirement is that, if any actors have bad intentions, their numbers are less than half of all participants - i.e there 49% bad guys in the worst case. Proof of work inhibits one of these 49% from corrupting the state of the ledger for their own purposes by:
Proof of work (and consensus, in general) is inefficient. In the Bitcoin case, the miners (so named because it is those performing the Proof of Work challenges that are rewarded with new coins and so effectively play the role of gold 'miners') spend their precious computing efforts churning away on seemingly pointless crypto puzzles. The answer itself doesn't even matter, it is the (carefully tuned) difficulty of the puzzle that serves to weed out bad miners.
As a result, DLTs (or at least the consensus mechanisms used to keep their copies synchronized) are inefficient relative to a single trusted third party (TTP) saying 'this is is the state of the database.' The question is then, why would anybody even consider DLTs?
Fundamentally, it boils down to a fear of having 'too many eggs in one basket', specifically, that by putting all your data eggs in one central TTP basket, you are worried about one of the following:
If none of the above 'eggs in basket' fears apply to a use case, then a DLT isn't appropriate, or at least isn't optimal because a TTP isn't immediately excluded.
Another potentially useful criteria for assessing the applicability of a DLT is suggested by the name itself - a 'ledger' records transactions and transactions typically involve multiple parties - each of which may have conflicting interests and motivations with regards to the state at any one time. An archetypical transaction is the transfer of some asset from one party to another. For instance, when Alice sends some number of Bitcoins to Bob, she creates a transaction that stipulates by how many Bitcoins her wallet should be reduced, and how many Bitcoins should be transferred to an address associated with Bob. Alice and Bob may have different ideas of how that transaction should be recorded. Bob might hope to be able to modify the transaction so that he receives more than the amount Alice stipulated - Alice the opposite.
If Alice and Bob do not have conflicting interests, ie they are not worried about the other acting nefariously to modify a transaction, then they trust each other in the sense given above and a DLT, with the overhead of consensus designed to protect them from each other, may not be appropriate.
Another notable feature of DLTs is so called immutability - the characteristic that it be difficult (if not impossible) for any party to retroactively change the database once a transaction has been verified and recorded. In Bitcoin, immutability is a consequence of how transactions are stored in blocks, a new block referring to an already existing block, so that you can't change a block without having to also modify every subsequent block that referred to it. Not impossible, but highly impractical. It is pretty clear how immutability would be useful in support of audit - the auditor would be able to see both the current state of the ledger, but also the history of how it got to that state. Or imagine a company's customer service ratings being placed on a public DLT such that a customer evaluating that company could be confident that no negative ratings had been removed.
But it's somewhat hard to reconcile the theoretical advantages of immutability with human nature and frailty - incorrect transactions will surely be added to the ledger - how to fix those mistakes. For financial data, it would be simple to add a second counter balancing transaction, eg that moved Bitcoin from Bob to Alice, in order to make corrections. In the world of accounting and double entry bookkeeping, this is accepted best practice to return a ledger to its original state after a mistake. But not all data that might be added to a DLT necessarily lends itself to such a clean remedy - there may be real consequences of an incorrect transaction that can't be merely cancelled by another transaction.
If immutability is not a desired characteristic of the database, then a DLT may not be appropriate.
In summary, we have three broad criteria that we can use to measure the applicability of a DLT to a use case:
In part 2 of this article, we'll use these three criteria to consider the applicability of DLTs to identity use cases. Some of the most talked about use cases lately include: users logging into applications, enabling the discovery of device attributes, providing identities to survivors of natural disasters etc.