¶ Introduction
¶ Actors
In order to understand the design and architecture of the Tokenization process flow, it is important to appreciate who is involved:
- NIMC - Custodian of Personal Identity in Nigeria and the Regulator empowered by law to set Standards for the flow of personal information in the country.
- Issuer - a natural person who:
- has been issued a National Identification Number (NIN) by the NIMC
- has an active NIN
- has visited the NIMC or one of its appointed Front End Partners (FEPs) to submit their Biometrics in person (not a BVN-generated NIN, produced as a part of harmonisation of databases)
- Relying Party - any non-natural person (Company, Enterprise or Small Business) wishing to verify the identity of an ID Holder. The Relying Party must have been issued a suite of credentials to enable it carry out verifications of Personal Identity. This suite includes:
- Enterprise LongID:
- Enterprise ShortID:
- API Credentials:
- X.509 Access Digital Certificate:
- Public/Private Key Pairs:
There will be a number of entities in the organization who will be responsible for this account. In all cases, those 'entities' MUST have been issued an active NIN, and thus also be in possession of a UserID.
- System Integrator - a possible intermediary party who connects directly to the NIMC and serves a front end API system to a Relying Party (RP). This may occur where the RP may not have the resources, wherewithal or capacity to establish a direct API connection to the NIMC.
In all cases, the actors MUST, without exception, be known to the NIMC.
¶ Digital Tokens
The Digital Tokens used in this architecture are as follows:
- Virtual NIN: This is the 16-digit Virtual Token issued by the entity described above as the "Issuer", expressly for a Relying Party and no one else.
- UserID: Every active NIN issued as a part of a digital profile, contains a UserID, which is readily available via the NIMC MobileID Application or via a USSD call on Feature Phones. In either case, the NIN must be linked to an active Mobile Number (referred to as the 'Trusted Number').
This UserID may be shared between ID Holders as it still presents a degree of anonymity and protects the original RAW NIN. - WalletID: Used in place of the Virtual NIN or UserID, expressly for API calls and Mobile or Web API integrations and calls.
¶ Verification Flow
To ensure full transparency of the flow of Personally Identifiable Information (PII), the Federal Government of Nigeria, under the auspices of the Ministry of Communications and Digital Economy, is implementing Tokenization Services for the transmission and usage of Personal Identity.
This is to ensure that:
- no entity may verify the identity of another person without the knowledge of that person.
- all Verification Entities (referred to as Relying Parties), must be known to the Custodian of Personal Identity (being the NIMC).
- each verification must be made with the express consent of the ID Holder, and/or at the very least, that they are aware of:
- the information that was shared with the Relying Party
- the date and time of the verification
- who exactly carried out the verification
- each verification transaction is properly logged and accounted for
- where a relying party is dependent on the APIs of a front entity (perhaps to offer other support services not provided by the NIMC), the end party that is actually making the request for PII is the only party that may gain access to that information
- an intermediary may not, under any circumstances, store information that was requested by another Relying Party
- the primary token to be stored in database of a Relying Party shall be henceforth the Virtual NIN of the ID Holder, issued by the ID Holder to the Relying Party.
¶ Possible API Integrations
There are two possible models for integration with the NIMC Tokenization APIs. These are designed to implement the Data Protection and Privicy initiatives whilst retaining most of the API Business Models of Integrators and Aggregators.
In either case, only the Relying Party to whom the original Virtual NIN was generator for may decrypt the data payload.
The Aggregator will not be able to decrypt nor persist the payload. Where an integration takes place that permits an Integrator to store or persist PII without the knowledge or express consent of the NIMC, this shall be determined to be a breach of data privacy and appropriate measures will be implemented to address such instances.
¶ Direct
¶ Indirect
¶ Use Cases
¶ Flow Diagram of the verification flow
Below is an overview of the flow of verification of the Virtual NIN
