A Personal Data Store Based ID Design

A foundational ID system design that enables individuals control over their data ensuring efficient service delivery.

A personal data store(PDS) is a virtual data store that enables individuals to gather, store, update, correct, analyse, and/or share personal data. The personal data store could be centralized or decentralized, however given the functions of a foundational ID and the need for universal inclusion and accessibility, a centralized approach is a better option.

This solution proposes a personal data store design that allows a user full control over their data (i.e the attributes), a specific attribute(s) is then chosen to be used for the purpose of deduplication. The attribute is hashed and stored (even for biometrics) in a different single-purpose database, hashing ensures the protection of the attributes.

The design is modular and includes the following core modules;

1. PDS database is designed as shown in the attached figure, the database structure implements a compartmentalized design with the tables linked by unique identifiers (key columns) created through one-way derivations to ensure unlinkability of the tables. The database is encrypted and accessed through a hardware security module.

2. Data provenance module, this module provides a record of transactions and operations on the personal data from it’s creation. Each transaction record is timestamped and digitally signed. The module is built on a ledger based technology such as blockchain that enhances the integrity of the records. All personal data is pseudonymized when logging the transactions.

3. Selective disclosure module, this is accessed through the user interface allowing the individual to select which data they wish to share with a given entity. This module also enables individuals to lock/unlock their credentials.

4. Granular access control module, this is the interface through which the system is accessed, the module defines the who, why, where, when, how and what in regards to access to the database.

Further more, for system administrators, a quorum functionality is included which defines the number of persons that have to sign off to allow a given transaction depending on it's sensitivity. 

5. Tokenization module, to share the personal data, users create single purpose time-sensitive tokens that are created through one-way derivations, that they share with the given entity that requires the data. The selected data is then paired with the token and locked with a password or biometrics. The data can be downloaded and stored, or shared by providing the token and password.

6. System monitor, this module monitors the entire system then logs and reports all transactions between any entity and the system and within the system itself. The logs are timestamped and digitally signed to ensure they are tamper-proof.

7. API module, this is the interface with any third party entity, the module implements two response modes, a Boolean response and answer mode. The Boolean mode allows a third party to verify a credential without knowledge of the credential. While the answer-format allows a third party to format questions and receive answers without access to the actual data, this can be optimized with the application of interactive machine learning.

The personal data store allows the user full control over their data as regards to use and sharing, by design the users consent to share their information or have it used.

Selective disclosure functionality, this allows the user to select what data they can share with any entity that requires the said information.

In transactions with third parties, Boolean response and answers format is implemented. This enables verification of a given credential without disclosing the actual credential or an answer instead of the raw data.

Unique identifiers (key columns) for linking tables in the database system, tokens used for third parties are all created using one-way derivation ensuring unlinkability among third parties or the tables in the database.

The solution itself could be implemented as a back-end to a digital identification system.

The solution is built based on a modular architecture, this architecture allows the users (.i.e governments etc) the flexibility to use the each module independently or add their own modules to achieve customized functionality.

The modular architecture also allows easy upgrading of the system in case a better solution arises or further functionality is required without affecting the rest of the system.

The system is designed based on a modular architecture, with an API interface that allows interactions with other systems.

The data is shared in open standards including XML and JSON over open protocols like HTTPS and REST.

The system allows for data to be shared in a number of ways including, pairing the data with a token and locking with a password which can be downloaded or the token can be shared independent of the system for offline use, further more the data can be printed and presented in form of an encrypted QR code format.

The system can be accessed through a website, an app or through USSD catering for users with low end devices and/or low literacy given the wide spread familiarity with the technology.

I have personally experienced the inconvenience of not having a credential to prove my identification and the frustration of not knowing the exact data that is recorded under my credentials, Mission Billion allows me a unique opportunity to contribute to the design of identification systems to avert such situations.

Ensuring efficient service delivery by government without compromising the full control feature over the data by individuals is a bit of a challenge.

A strong legal framework needs to be in place to define procedures to follow to access and use sensitive data and define the scenarios in which these procedures can be used say for law enforcement.