Interoperability and the Blockchain Hammer, Part 2

“While DLT applications often target the removal of the ‘middle man’, this may not be a realistic goal in [identity management] applications due the context [sic] of identity maintaining a profound need for trust.” Paul Dunphy and Fabien A. P. Petitcolas

DLTs and blockchain continue to disrupt and reshape the traditional financial services ecosystem having been used by over 100 million people across the world to transfer trillions of dollars of value, according to the World Economic Forum. Blockchain, as a tamper-resistant database shared on a decentralized, peer-to-peer network, may move beyond the financial services and into supply chain systems, intellectual property and identity, but when and how is uncertain. There are aspects of blockchain appropriate to identity systems and we’re eager to show how they can be best integrated.

There have long been discussions (and there have been long discussions) about issues with traditional identity management systems:

1. Ownership and sovereignty. Historically, identity systems were put in place to secure access to information reserved for topics between the business and the user (for example, my email address). The information is stranded within the business, for their exclusive use, and it is non-portable. Worse, when I discontinue use of the businesses services, personal information was often left behind.
2. Discovery. When a user wants to introduce a business (or a relying party) to their preferred identity information provider they’d go through shared common registries (starting with X.500, followed by proposals to use DNS, and even the optics of large identity providers, such as Facebook and Google). Such infrastructure results in registry(ies) able to observe patterns in the use of the registry or, in my view, a panopticon of sorts.
3. Veracity. The systems must determine who is considered to be an authority when it comes to asserting an identity (or attributes thereof) and how the relying party trusts the assertions made by a verifier.
4. Proof of consent. Historically, largely compelled by regulatory requirements, relying parties retain irrefutable evidence (e.g. an auditable log) to ensure compliance with the regulations. It is, however, very uncommon for businesses to share these logs with the user in question. It is even less common to demonstrate a user’s participation in the agreement.

Blockchain quickly became a hammer to finish these nails. But what is unique about blockchains that allow us to solve these issues?

Ownership and sovereignty

To overcome this problem, architectures are moving towards distributed systems, where the oversight of such a distributed database is provided by an independent board. Some turned to DLTs as a means to resolve this concern. However, DLTs are still “controlled” by a third party (via oversight of the chain itself). Blockchains and DLTs don’t directly contribute to achieving this goal, however. An individual “owns” an entry in a public (or private) ledger system no more so than they may “own” an entry in a centralized system. Ownership and control has to be left exclusively in the hands of the individual. As such, it should be housed in systems the individual is in complete control of.

This problem is not solved well by making use of blockchains and DLTs.

Discovery

To this day, discovery of most internet resources starts with the domain name system (DNS). Other protocols, layered on top of DNS, facilitated more refined resolution, including one’s identity (as was, for example, the early versions of openID). However, these approaches left data exhaust in the form of transaction logs, which left user interaction activities exposed to analytics. PKI-based approaches (through exhaust from CRL and OCSP checks) had similar disadvantages. Blockchains can assist here, provided that the ledgers are highly distributed, with no controlling authority having visibility into the exhaust of the collective chain.

So, this may be an appropriate use of our metaphorical hammer.

Veracity

Data authenticity and trustworthiness has long been a concern in the design of identity systems. Looking back in time, this was something that was addressed formally in ISO/IEC 9594-8 (aka X.509), as well as more informal trust models such as “webs of trust”, e.g. PGP. Such designs required relying parties to mutually recognize named authorities (centralized CAs for X.509, social network webs in architectures like PGP).

There are two characteristics of veracity worth noting: mutual agreement on a vocabulary (all parties agree on the meaning of “surName”), and mutual agreement on the processes involved in verifying their values (can I trust who is asserting a surName of Smith).

These interoperability requirements are not solved by blockchain technology what-so-ever. A case could be made for recording affirmations by other relying parties in a ledger. However, this would still require a trust framework (centralized or otherwise) for such assertions to influence another relying party’s risk assessment.

Our hammer is not needed here.

Proof of consent

Collecting and recording consent in an interoperable manner is a relatively new entrant to the identity management party. When identity architectures are closed, proprietary systems, compliance teams will ensure relying parties record collection, for the sole purpose of complying with regulations. However, they rarely expose that record of consent back to the data subject themselves.

There has been progress at the interoperability level. ISO/IEC 29184:2020 incorporated the Kantara Consent Receipt v1.1 recommendations. This is a good first step. But, if a user wants an auditable record of these conditions, separate from any records at the relying party (or data custodian/processor), they must resort to other means.

What capability does blockchain introduce for demonstration of consent? For starters, it could serve as the medium for public record keeping by processors and consodians. However, it may not make sense for an individual data subject to use. Just as we seek a distributed means to discover identity information as discussed above to avoid leaving a trail of data fragments on who a user interacts with, the public (or even private, within a trusted community) recording of consent leaves behind indications of who the user may have interactions with. Somewhat analogous to disposing of store receipts intact in the waste bin. Individually, they do not mean much, but collectively, they begin to reveal patterns of activity, and retailer preferences for those rummaging for such information.

The new hammer may add some value here, but perhaps not quite as advertised.

Assessment of our toolbox

Let’s summarize my observations:

If I were to assess how blockchain and DLTs tools improve my toolbox, I would conclude that it is prudent to include it, but not as the universal, all-in-one tool as it has been marketed.

I organize my identity management toolbox putting my most commonly used tools (such as cryptography, federation, privacy, and compliance tools) where they’re easily accessible. And, while I won’t use it most days, I will likely keep my blockchain hammer, just in case. I’ll put it next to my set of Allen wrenches, which I don’t use often, but I’m glad it is there when I need it.