NeXplain and Digital Identity

 

Digital identity is the identity that a person has on the internet. Every action we perform from our phone or computer leaves a series of traces and data that, without knowing it, we provide to the network. This goes beyond our email and address, it also includes photos, bank details, what we buy, what we look for, and even our political profile based on the content we read, or what we invest our time in.

 

There are times when both identities (physical and digital) come together and mix with the data of where we have been or, even, what we talked about. Data that companies that participate in all these virtual sites, buy, sell and share among themselves and with others with whom a natural person might not want to share certain information.

 

But it also happens that, sometimes, the digital identity does not necessarily coincide with the real one, due to the natural desire, sometimes the need, of the person to promote themselves or show the best version of themselves, or because they want to hide their true identity.

 

That is why, as the world goes digital, in certain areas the need arises to “authenticate”, or validate the identity of the person. This is a process, usually digital, that evaluates, validates, identifies and certifies that a person is who they say they are. For this, it is necessary to compare identity data points with some physical data, such as the fingerprint or facial biometrics.

 

But a balance must be found between free access to personal data by anyone and verification of the person in an official way by some organizations/institutions. For this, a new figure arises that is the Sovereign Digital Identity where the user is the owner (and master) of their digital data.

 

Javier Puyol Montero in Confilegal explains what would be the 10 PRINCIPLES THAT GOVERN SOVEREIGN DIGITAL IDENTITY, according to Christopher Allen, creator of the term “Self-Sovereign Identity ”.

 

A self-sovereign identity must attend to the following characteristics:

 

(I) the existence of the identity of a person, and this independently of the administrators or identity providers;

 

(II) the control by the person of their digital identities;

 

(III) full access by people to their personal data;

 

(IV) the transparency of systems and algorithms;

 

(V) the persistence of digital identities;

 

(VI) the portability of digital identities;

 

(VII) the interoperability of digital identities;

 

(VIII) compliance with the data economy; and (ix) the protection of the rights of the person.

 

And, above all, it constitutes a first step in the construction of a global identification system, which includes both standardization, as well as functionality in all types of applications and developments.

 

Nexplain, in addition to its technology for the identification and verification of people in migration and borders and states, works with personal data that require special protection. It has also created its own Digital Identity in the On-boarding process for the project ImmuvID The ImmuvID project deals with extremely sensitive medical data that is used to grant entry (or not) to certain activities/building and border crossings. That is why for us it is absolutely a priority to comply with the 10 commandments of sovereign digital identity when verify and certify the identity of the person and the verification of all data provided (including health data) to emit the maximum guarantees to both, states / organizations that require knowledge of these data and users who decide when and who will access them.

 

Identity Collection

With the ImmuvID System users register and identify themselves either through mobile applications or through the web front end. In either of these environments the user can supply data through:

 

• Forms which collect self declared information from the user. At a minimum this will include Name, Date of Birth and Nationality although this could include other fields on customer request. 

• Document Image upload – the user uploads an image of a document which can be verified on the server side, either by machine or human. As this is a state ID the ImmuvID system will accept images of the ID and can complete other checks, including anti-forgery and biometric tests. This should be considered verified. This process can include state backed API confirmation, for instance lookup and data confirmation based on document number

• Biometric check – the user uploads a picture of themselves take at that point in time, which can be compared to the image in a photo ID. (Only available on mobile).

 

User Data Collection 

Naturally the ImmuvID system must collect some user data, however, we treat this data as important personal data which we will not use for any purpose outside of the ImmuvID system. We will retain this data for as short a period of time as possible.

 

Purposes of Data Collection 

The following are the purposes for which we will create data:

 

• To create a user record of vaccination or test result. We need a minimum set of identity information to create a record in the database for a single user. 

• To add the user to the appointment scheduling system. It is likely that we will need to know your address in order to offer appointment slots with as little travel as possible. 

• To send the user appointment details. We will need some means of communicating details of the users appointment to them, either email, phone number or push identifier. 

• To validate the user’s identity. We collect user documentation and possibly national or health identifiers to validate the user. 

• To complete public health reporting. It is likely that some customers will want to ask additional questions for reporting purposes, fields such as gender, race etc.

 

Statement of Data Protection

Some personal data must be collected in order to operate the ImmuvID system. The system will only collect required data. The data will only be collected to identify you, book services, and confirm your covid status, either through test or vaccination results.

 

How ImmuvID treats user data 

ImmuvID does not trade in user data in any way and will not do so.

 

We have a legal requirement in Europe to operate under the General Data Protection Regulation (GDPR) and personal data which is collected and processed is kept confidential and secure. To fulfil our legal obligations, ImmuvID and its suppliers have implemented technical and organisational practices to protect personal data from loss, unlawful access, destruction or damage. 

 

While the GDPR only applies in Europe, we intend, as much as possible, to follow the same practices in all jurisdictions. 

 

Where will personal data be processed? 

As much as possible, Immuvid will aim to process data in the jurisdiction in which it is processed. The Immuvid system is designed to allow for deployment either to the cloud or on self hosted hardware. It is possible that in some parts of the world, deploying to the cloud may mean that personal data does leave the original collection jurisdiction. 

 

How long will information be retained?

Each customer is in control of their retention of data. However, Immuvid will look to retain data only as long as legally required.

 

Data Protection Functionality

• Users can access their personal information 

• Users can correct inaccurate information, or update incomplete information 

• Users can request restricted processing of their information

• Users can request deletion of their personal information 

• Users can download their personal information in a portable format Users can object to processing of their personal information 

• Users can record a complaint about the processing of their data 

 

Data Ownership in the ImmuvID system 

ImmuvID customers are the Data Owners of personal user data at all times. Immuvid will be a Data Processor. Therefore we must publish the contact details for a Data Protection Officer (DPO).

 

Our system makes use of the FIDO system of https://fidoalliance.org. This means that users are identified by a pair of public and private keys. The key pair is generated on the device user and the public key is shared with the server-side system. Once the key is shared, the messages from the server to the client are signed using the public key, which only the user with the private key can decrypt.

 

Nexplain making the world a safer place.

Share this article:

Leave a Reply

Your email address will not be published. Required fields are marked *