Mobile Identity Management on the Blockchain

Marc Updated
 
0.0
 
0.0 (0)
2   0   0   0

Introduction

At first glance, digital identity and blockchain seem to have little in common. While digital identity management cares about identifying entities and persons, aiming to establish a trustworthy binding between the real-world subject and its digital representation, distributed ledger technology (DLT) and decentralised applications (DApps) are opening up fields of applications we've only just begun to explore. This article provides some insight into how digital identities and blockchain fit together.

Mobile Identity

When it comes to identity management, self-sovereign systems are becoming more and more important. What do we mean by that? In a traditional system, personally identifiable information (PII) are stored with an identity provider (IdP) who would release the data to web service providers once the person has been authenticated. Having said that, PII are exposed to risks outside the user's reach, and IdPs have to be fully trusted. With a self-sovereign identity system, those issues are gone. The idea is plain simple: No one but the user will ever gain access to PII. Having said that, PII cannot be stored with an IdP.

One popular example of a system implementing self-sovereignty is uPort, a mobile identity app developed by ConsenSys (I am neither a staff member nor a shareholder, in case you wondered …). With uPort, PII are stored solely in the app. The smartphone and the app combine into a two-factor protected identity credential; factor one is the smartphone (to have), factor two is the fingerprint (to be) or, alternatively, the PIN (to know). Another interesting thing about the uPort app is claims. A claim is data structure representing one or more properties about the user, the one and only person having control of the digital identity, created by some third party who made them. Ultimately, claims sum up to a digital reputation from which the user can select whatever they deem appropriate in the context of a particular transaction. Following the paradigm of full control over PII and other personal data, a claim will not be stored in the uPort app unless the user wants it to be there.

 Among the potential issuers of a claim we find public authorities asserting the user's identity based on official identification documents, or a private institution claiming the user's current membership. Claims may contain PII as well as other user-related data, like car registration, address, healthcare information, and many more. Claims are digitally signed in the uPort app by those issuing them, hence securing integrity and authenticity. To the recipient of a claim all that matters is origin. Recipients will decide whether PII can be trusted based on trust they have in the issuer of a claim.

Skip This If You Know About Ethereum And Smart Contracts

After the world has seen Bitcoin, the mother of all blockchains, other distributed ledger networks have emerged that apply blockchain technology in a fundamentally different way. Take Ethereum for example. Like Bitcoin, Ethereum provides for the transfer of the network's native currency, Ether, between accounts. However, accounts can do much more than just send and receive Ether – they can be programmed to act as a virtual computer. The Ethereum Virtual Machine, or EVM for short, is a Touring-complete engine. In other words, you can write programs on the EVM as you would in C or Java. Those programs are called smart contracts, or simply contracts.

Everyone can deploy contracts on the Ethereum network, for all to see and use. As they are actually Ethereum accounts, contracts can be referred to by their address on the network. Other accounts would call their functions, quite like a remote procedure call, and by doing so, induce a permanent change of the overall network state, because that's what smart contracts do: store and update data on the blockchain. All of a contract's logic and all data are fully transparent on the blockchain, everyone can inspect the code, scan data, not only current values, but also the past – there are no secrets.

As contracts consume resources, like electricity, storage and CPU, running them requires an operation fee payable by those consuming functions. The fee is expressed as gas in Ethereum which translates into Ether. The more complex, storage-consuming or CPU-consuming the contract, the higher the gas requirement, hence the Ether you have to invest to use it. That makes programming of a contract an art in itself, striving for lean, optimised code.

Smart Contracts For Identity Management

So far we know that claims are digitally signed. But this only means that integrity and authenticity of the data has been secured. As a recipient of a claim, how do you know it is truly about the sender? How do we know it's not another user's claim replayed by the sender? This appears to be the central question. Answering it means to sketch a concept that's comprised of identifiers, addresses, and cryptography. Let's go through this step by step.

(1) Initialise

Illustration 1: Initialise the app

Initialisation of the uPort app comprises, among others, the creation of a unique uPort ID and a crypto key pair.

(2) Authenticate

Illustration 2: No blockchain involved

In order to prove they are the legitimate user of uPort ID 4711, the user would sign a message to a web service. Because the public and private keys were created by the uPort app, rather than by a certificate authority, the public key is unknown to the outside world and web services remain unable to verify the origin of the signature. All that the web service has got so far is a data packet claiming the sender was uPort ID 4711.

(3) Back to square one – initialise with blockchain

Illustration 3: Initialise using the blockchain

In order to make the whole idea work, the initialisation includes another step: writing data to the blockchain saying, in essence, that there is a uPort ID associated with a given public key.

(4) Authenticate … once again

Illustration 4: Authenticate using the blockchain

This time, the web service can verify the signature by looking up the public key that goes with uPort ID 4711. Doing so asserts that the user in control of uPort ID 4711 must have signed the data packet. In other words, the holder of uPort ID 4711 has been authenticated. Up to this point, the only information the web service has is this: identity 4711 has just been authenticated.

(5) Store PII

Illustration 5: Store PII

Claims are signed by the issuer, sent to the uPort app and stored by it on the smartphone (blue document). Let's assume a public authority to be the provider of a PII claim based on official documents. By issuing the claim to the user's uPort app, the authority promises to have taken the necessary measures to ascertain the quality of the claim and the delivery of it to the rightful uPort ID.

(6) Passing PII to web services

Illustration 6: Passing PII from the app to a web service

If a web service requests PII from the user, the appropriate claim is transferred to it, given that the user consented. The signature of the claim is verified by the web service off-chain (see signature verification service in the illustration), and yet, we might ask: How does the web service know that the PII actually belong to the owner of the digital identity? Couldn't they be a claim that they received in advance and now replayed? The answer is in the claim itself, as the issuer has originally bound the claim, and therefore the PII, to uPort ID 4711. The verification of the message holding the claim is done as shown in step (4), which – other than the claim's signature – is on-chain.

Now the story is complete: uPort ID 4711 has authenticated and sent along a PII claim that is signed by the issuer. As part of the claim data, the issuer confirms the PII belongs to uPort ID 4711. This is the ultimate proof that the user who authenticated as uPort ID 4711 is the person to whom the PII apply.

Conclusions

The key question is: How can the world associate a technical identifier, like uPort ID, to a public key? Once this question is answered, the rest follows. In this document, we have focussed on blockchain, but we could as well go without it. One might argue that blockchain is essentially a database, even though a very special one. So why blockchain after all? Well, there are good reasons. Let's have a look at some.

  • No particular owner or administrator, therefore no central authority to accumulate risk or get compromised.
  • Issuers of claims need no safeguards, and no legal consequences will ever arise from database failure or unintended manipulation, as the blockchain is immutable by design.
  • No need for service level agreements with providers from whom you would depend for years to come.
  • Immune to attacks, like DOS (denial of service) and others. However, there have been successful attacks, but they all happened because of smart contracts that have shown to expose vulnerabilities by design in the aftermath.
  • Blockchain is immutable and data can only be changed by the very contract they belong to. The whole design of the smart contract, the whole transaction history and all data is visible to everyone at all times. There are no secrets on the blockchain.
  • Blockchain infrastructure is ubiquitous. No need to develop, test, deploy and operate data services on your own. Everyone can create and deploy smart contracts.

User reviews

There are no user reviews for this listing.
Already have an account? or Create an account

Responses