Digital identity - why we need it and how to build it ?

In this article I'm going to explain why a lack of reliable solution for a digital identity is a a huge problem we have to solve.
Also I will present my vision of a digital identity. I'm going to define what is digital identity and what are main use cases for the digital identity..

Why we need a reliable solution for the digital identity ?

The world we live in is changing very fast and became a digital. More and more activities is migrated to the virtual world that is based on the internet.
But ... one of the bigest problems we have in a digital world is ownership.

A good example of this issue is a problem of money. We still do not have a digital cash that we could simply use in the internet. Our money are imprisoned on a bank accounts. We can access them using a debit or credit cards. But it's quite easy to steal a card details and spend somebody's money. It's because there is no real digital ownership behind payment cards. Everyone can copy it and start using on someone's behalf.

So far we do not know how to establish an ownership for the digital assets in a reliable way. The 'reliable way' means a technical solution that guarantee two things:
- we can always identify who is the owner of a digital asset (it can not be changed)
- owner is able to controll the access to the digital asset (no one can simply copy it)

The key aspect of the ownership is identification of the owner. Because of this reason we need a digital identity that will make it unmistakable to identify who is the owner of a digital asset.
On the fundation of digital identity we can build a digital ownership. Tha's why reliable solution for the digital identity is so important. We can still live without digital identity but in this case the digital ownership will be only ilussion.

How digital identity platform should look like ?

The digital identity solution should be a ditributed platform that is NOT controlled by any government, company nor any other organization - same as email. It mean's that every one can run it's own identity server (IDA) in order to collaborate with a group of users in a secure way. For example local community can run it's own identity server in order to do a digital voting.
Every single digital identity should be fully controlled only by the owner (means a real person or group of persons that stands behind particular digital identity).
Some attributes of a digital identity can be controlled by the third party (eg. governent can have controll on the VAT number that is assigned to the particular identity), but identity as a whole should be controlled only by the owner.
Below you can find basic definitions and use cases for the digital identity solution.

1) DID - Digital IDentity

It's a pair of public and private key that is controlled by an identity owner that can be a person or group of persons (like organisation, institution, company etc.).
Private key is protected and stored in the IDH (Identity Holder) component. Public key can be published on the IDA server  (Identity Authenticator). 

Digital identity has at least one attribute called name that is unique for the IDA server.
Each identity has it's own DID address that associate it with an IDA server.  DID address has following format:

{DID Name}#{ip or domain name of IDA server} eg. Pawel.Mostek#someIdaServer.com

2) Attributes of digital identity

Each of digital identities have a set of attributes that describe digital identity and make it serchable. Each attribute is a triple:

- name 

- value 

- metadata

  

Metadata describe how to handle attribute - eg. what algorithm has been used to encrypt attribute value.

Each attribute can be authorized by any other digital identity - it means that the metadata of the attribute contains digital signature of it's name and value (eg. in a form of json token) provided by other identity.  If attribute is signed it means that authenticity of this attribute has been confirmed by other digital identity (eg. governent institution can confirm VAT number assigned to digital identity registered on some IDA server).

Attributes can be stored on both IDH and IDA. Attributes stored on the IDA can be public (plain text available to everyone) or private (encrypted and available only to specified identities).

3) IDH - Identity Holder

It's a software installed on the device that is fully controled by the person that is identity owner. Public and private key are always generated by the IDH.
IDH connects to IDA in order to publish the  attributes together with metadata assigned to digital identity. 

IDH always sends requests to IDA  and it never get any incoming requests from any external software (it means that only IDH can initiate actions regarding digital identity).
IDH stores private key in an encrypted form. Encrypting key is stored on the IDA server and is sent to IDH after succesful authentication. It means that private key will be safe even if IDH will be hacked.
One IDH can store multiple digital identities controlled by the same person. IDH can connect to different IDA servers - it's not tied to only one IDA - but each DID SHOULD be assignet to only one IDA server. It's in order to controll and verify IDA server in case of data leak.

4) IDA - Identity Authenticator

It's a server that provides REST API to interact with digital identities. It can be a dedicated server or any web application that is DID enabled (it means it provide endpoints that allows to deal with digital identities embeded into a web app).
IDA provides methods to search digital identities and methods to fetch data published by DID (eg. public key) and other methods to interact with DID (authorize, authenticate etc.).

IDA also store the decrypting key for the DID's private key (DID's private key is stored by the IDH in an encrypted form).

IDH authenticate to IDA in order to execute actions on behalf of DID.

IDA server does not store any sensitive data - it's only kind of proxy between DID/IDH and external world.

5) ID Framework

It's a set of libraries that helps developers to build web apps that are "Digital Identity Enabled" - means that digital identity can interact with such a web app (eg. authenticate)

DID - Digital IDentity ecosystem

Use cases for the digital identity (DID)

1) Identity controll

 - create sub identities (sID) based on main identity (mID) that inherit specified attributes from       mID

 - controll visibility of DID - create private/encrypted DID visible only to other DID that has 

2) digital ID finding, attributes sharing and verification 

- find public key of specified DID based on DID address

- verify if public key of specified DID is valid - eg. was not revoked

- find DID with specified attribute value (eg. NIP value confirmed by specified gov DID)

 - publish and revoke attributes of DID

 - authorize (sign) attributes of other DID

3) Authentication

- IDH starts (and controls) authentication process to third party services or web apps using IDA 

4) Authorization

- DID owns a signed attribute (token) that contains privilages from third party service or a web app. This attribute allows DID to execute actions in a third party services or a web app.

5) Expressing a will or digital voting

- generate anonymous voting ID (vID) that inherits from main ID
-  single voting - vID owns a privilage (that is a signed and private attribute) to execute one of several actions in a third party service - user can select and execute exactly one action

- multi voting - vID owns a privilage (that is a signed and private attribute) to execute couple of several actions in a third party service - user can execute only specified number of actions
- voting veryfication based on the anonymous vID

6) digita value/asset emission

- publish digital asset (eg. picture, film, article etc.) as an attribute owned by the identity

- emit digital value (eg. digital money) as a signed attribute backed by the privilage to execute usefull action (eq. pay tax to the gov, or execute an action in a web service)

7) digital value/asset controll an protection 

- lock/unlock access to digital asset

- sale digital asset - transfer ownership to other DID

- transfer digital value/money -  transfer ownership to other DID

Pull security model vs Push security model or how to unlock a door properly

In this article I will present two security models: pull and push. I will use a simple example of the Electronic Door Unlocking System (EDUS) in order to explain how both models works.

Probably everyone had something to do with the EDUS. It's most common security solution that we can meet in every office or public building. User gets an RFID card that allows him to unlock doors. One have to close the RFID card to the reader and that's it we can hear 'beeep' and door unlocks.
It's quite old solution that is based on the pull security model

Let's start with simple diagram that shows how EDUS based on the pull security model works now:

pull security model

SP - service provider or electronic lock that opens a doors
IDA - Identity Authenticator or application that knows who can open which door
IDH - Identity Holder - in our case it's RFID card but it can be any utility that can keep user secret data - there is always a real person behind IDH that want's to "open the door"

In this solution the key role plays the SP component that pulls identity details from the IDH and sends it to the IDA. It means that every SP has access to the secret data of each IDH registered in the system. Because of this reason we have to provide protection to every single SP element in the system in order to protect users secret data. The whole system will be compromised if someone hacks one of the doors and start copying the users secrets data.
It makes this solution extreamlly insecure. If you have 100 doors in the building then you have to provide protection to each one of them to make sure your building is secure and all users data is secure. It makes the pull security model compleatly broken.
Nevertheless pull security model is widly used in a lot of IT solutions. Good example of such broken solutions are card payment systems.  One have to share the payment card details with every single payment terminal.

Sum up - in the pull security model we have to share our identity details (that is usually kind of secret) with every single endpoint in the system that plays simple role of a service provider. In this solution we have to protect every single endpoint to keep system secure. It makes this solution extreamly insecure.


As an oposit to the pull security model I want to present the push security model. I will use the same EDUS example in order to explain how it works.

push security model

In the push security model the most important component is IDH. It controls whole process. First it pulls ID from the SP (a doors ID in our example).  Next it push request to IDA in order to unlock the doors. IDA do a processing and based on this send request to SP (request is sent only if user is allowed to unlock the door or it does not take any action if user is not allowed to unlock a door).
In this model we do not share any secret data with the SP. SP is a simple 'executor' - it only do a job it has to do (unlocks a doors in our example).
One can say that in this model we have to protect much more IDH's but each IDH is protected by the definition as it's something personal that has direct owner that protects it. There is also IDA that can disable IDH in case it has been compromised (more likely we get info about compromised IDH than about compromised SP that does not have direct owner).
Ofcourse in this solution RFID card CAN NOT play the role of the IDH. Nowadays the most natural candidate for the IDH is a smartphone.

Sum up - in the push securty model the IDH plays the most important role. It connects only with trusted IDA and it's only component that can initiate action in the system. The role of the SP is reduced - it's a simple executor that can not initiate any action.  Users secret data is shared only with limited number of trusted IDAs.


Comparison: 
In the pull security model we have huge number of endpoints we have to share our secrets with. Those endpoints can potentially copy our secret data and initiate actions on our behalf.
In the push securty model only IDH can init an action and we share our secrets only with limited number of trusted IDAs.

From the historical perspective the pull security model was much simpler to implement as there was no smartphones that could play the IDH role connecting directly to IDA.
It's a historical reason that we can use to understand why pull security model was implemented in the past.
In my opinion there is no good reason to keep the 'pull securty model' anmore - we should replace it with push security model.

Short introduction

I'm going to write here about broken security model we have nowadays in the IT and whole digital world. Starting form the electronic door unlocking system through the login process ending with the card payment systems like Visa or MasterCard.

All those solutions are broken from the security perspective. Those solutions provide only an ilusion of security but there is no security behind them at all. I will try to proof it using some simple examples.

I want emphesis that I'm not a security expert. I'm a softawre architect with a quite big experience in IT.
My main goal is to share my findings and my knowledge regarding IT systems and security.
If you find any mistakes in my reasoning that's greate - please let me know about it - I am open to criticism.