1.1 Objectives
- Provide a means for persons issued a NIN and who is entitled to the National eID Card to have a visual, high security representation of the National eID Card on iOS and Android SmartPhones.
- Provide a secure means of presenting the National Identification Number (NIN), in a format that can protect the NIN from seeding, cloning and duplication.
- Present a foundation for harmonization of tokens. As the ecosystem evolves, other tokens such as the BVN, Voters ID (VIN), and even a driver’s license is possible, subject to the approval of and collaboration with the relevant functional agency (such as NIBSS, INEC or FRSC).
1.2 Background
For a myriad of reasons, there are a growing number of Nigerians whose NIN and/or Personally Identifiable Information (PII) is subjected to harvesting or being stored (persisted in technical parlance) by verifying agents (hereinafter referred to as Relying Parties).
Furthermore, NIMC does not have total visibility on the actual parties carrying out verifications of ID Holders.
Personal Information is also stored in disparate databases around the country with little control. How it is shared, how it is persisted at rest and in transit is largely unknown.
Likewise, the NIN holder is not advised of any subsequent access to their personal information. The entity storing the PII most likely did not advise the NIMC (where they originally got the source data from, including the NIN), that they had:
- Complied with NIMC’s strict data storage and encryption regimes for data transmission
- Obtained an approval from the NIMC to persist personal data in their databases
Finally, the ID Holder may not be aware of who carries out the exercise, where the verification was made nor the type of information that was shared or how it was stored (or not).
Tokenization of personal information is not new. Banks have been using it for decades to protect financial transactions. Fintech companies are also issuing temporary (use-once) bank account numbers for customers to carry out online transactions. It expires once the transaction has completed.
Apple, has recently introduced tokenized email addresses in iOS 15, to protect the original iCloud email address from cloning, for similar reasons.
The World Bank has also advised many a Government to implement some form of Tokenization to protect Personal Information.
1.3 Existing Workflow
Scenarios currently exist where:
(a) A person requires a product or service from Company A (Sub-Agent). That company does not have a direct relationship with the NIMC (for any of a number of reasons).
Company A relies on Company B (licensed Verification Agent) who DOES have a verification agreement with the NIMC and offers such services via API connections (amongst other support services), which the NIMC may not be offering.
- Company A requests for information on the NIN Holder via Company B’s API.
- Company B has API access to the NIMC Verification Service and passes the request to NIMC. It does not however, let the NIMC provenance of the verification request. It does however ‘claim’ responsibility for the request.
- The ID Holder is most often also not aware of the verification flow nor whether or not their Personally Identifiable Information (PII) is stored by Company A, Company B or any other intermediary or repository
- In its own right, and as a going concern, Company B charges Company A a premium for the query, and passes a minimum fee to the NIMC.
- There is a very minimal dataset for accountability and transparency in the verification flow as described above.
- Company B does not advise the NIMC of the existence of Company A in the workflow chain
(b) As an addition to scenario [a], Company A itself may also offer similar services to Company C (Sub sub-agent), again creating a tunnel unknown to the Custodian of Personal Identity in Nigeria, nor the actual owner of the information.
Thus Tokenization of the National Identification Number (NIN) was introduced to mitigate against these and other scenarios, strengthen data privacy rules and prepare for the eventual passage into law of Data Protection Regulations.
The Federal Government of Nigeria is thus taking pro-active steps to enhance the Protection of Personal Information and prosecute any and all who may fall foul of these initiatives.
1.4 The Virtual NIN
– Privacy by Design –
The Virtual NIN (vNIN) is designed to replace the raw 11-digit NIN for everyday usage. Where until now, the raw NIN had been shared and stored by various entities mostly without the knowledge (or consent) of the ID Holder or the Custodian of Identity in Nigeria, the NIMC.
The Virtual NIN has the following characteristics:
- It consists of 16 alpha-numeric characters, starting with 2 letters of the alphabet.
- ISO/IEC 7064, MOD 1271_36 is employed as a check digit algorithm. This means that the Virtual NIN may be validated BEFORE it is submitted for verification via API or stored as a part of a payload.
- It is issued by an ID Holder, either via the NIMC MWS MobileID app or via USSD on a Feature Phone, and only by the NIMC.
- A Mobile Number linked to a NIN is required to participate
- The Virtual NIN is issued exclusively by an ID Holder who has been issued a NIN by the NIMC and no one else. No NIN, no vNIN.
- The vNIN can only be issued for a specific Enterprise (could be a public or private company or a Government agency).
- It may be stored in a database along with personal information of the ID Holder (in place of the raw NIN, which after the cut off date, will be illegal to store or persist in any database).
- It is non-transferable. This means that only the ID Holder (called the Issuer) may use the token, and the Relying Party (verifier) to whom it is issued to.
- It expires after 72 hours (by default). This means that each time a reference needs to be made to the token, the Relying Party MUST communicate with the NIMC to respond to queries on the verification. That it expires after 72 hours does not mean there is no record of it at the NIMC. It simply means that the Relying Party has a responsibility to verify the vNIN via an API call within 72 hours of its issuance or request a new one from the Issuer.
- The vNIN bears absolutely no resemblance to the original Raw NIN (11-digit number issued by the NIMC). This pseudonymity is essential for data privacy and to reduce the proliferation of personal information in the public.
- The vNIN may be verified ONCE ONLY within the lifecycle of the token. In other words, where it was issued to say Bank A, only the same Bank A may verify the vNIN within that lifecycle. If however the token is taken to Bank B or Telco C, it will not work - valid or not, as the Issuer did not issue the token for any enterprise aside from Bank A. That is what the Federal Government determines as having provided User Consent.
The Virtual NIN issued by the ID Holder (to be known as The Issuer), will now replace the raw 11-digit NIN in all databases around the country, with the exception of the National Identity Database (NIDB) domiciled at the NIMC.
It will become illegal and punishable to the full extent of the law to store or attempt to verify the Raw NIN.
1.5 Data masking and pseudonomization
Data masking is defined as a resource used to hide sensitive data from those who do not have a clearance to view them. For example, this allows an agent or staff of a Relying Party to view a database record without having access to the actual sensitive NIN. Data masking has become increasingly important, for example, with the enforcement of the EU General Data Protection Regulation (GDPR) introduced in 2018.
The following steps demonstrate the use of masking to obscure your National Identification Number since it is personally identifiable information (PII).
| Component | Description |
|---|---|
| ID Holder | A person issued and in possession of an active NIN. This person may be located anywhere in the world, not necessarily physically present in Nigeria. Hreinafter referred to as The Issuer. |
| Relying Party | An Enterprise (company, small business or any other non-natural person) who wishes to carry out verification of an ID Holder. This also includes API connectivity directly or indirectly to the NIMC. |
| Agent | A natural person who operates on behalf of the Relying Party to carry out verifications on their behalf, whether or not they employ the use of an API to do so. |
| Claims | Elements of a dataset returned in an encrypted JSON Web Token format, which may include personally identifiable information (PII) such as a person’s name, date of birth and a photo image |
¶ Components
| Component | Description |
|---|---|
| WalletID | Used for API integration |
| UserID | May be shared between peers yet protects the major part of the NIN |
| NIN Hash | Contained in the Digital NIN Slip as part of the token verification claims. |
| Virtual NIN | Provides full pseudonymity for the ID Holder and user consent to a Relying Party (RP) for a limited lifecycle. |
¶ Breakdown
| Token | Example | Can be Shared | Use Case |
|---|---|---|---|
| UserID | ABCDEF-1234 | Yes | In place of Raw NIN for day-to-day exchange or persistence |
| WalletID | s.YnCGW77YwW6WYIM9g6noOUeL | via API | For MNO, Fintech or Mobile Integration |
| NINHash | daf58f322101bd9da52089ec86dcd3846515860d | Yes | Scanned via Aztec Barcode |
| BasicID | fa8bca616b9f7d9fe1bf7ee223cc006992a8be8c | Yes | Scanned via QR Code in MobileID |
| FullID | 2078e5a24925723e1cdfa9232f40d8ec302c813a | Yes | Scanned via QR Code in MobileID |
| Virtual NIN | AB-123-456-789-123-RS | Yes | Day-to-day transactions. Tied to a Relying Party (RP) and time bound. Cannot be reversed to obtain the raw NIN. Link only known to the NIMC. Can be issued via Smartphone or USSD. |
- Issuer must have an active NIN and a Mobile Number linked to that NIN. They must also be in possession of either a Smartphone with the NIMC MWS MobileID app (and Internet Access), or a feature phone with a mobile number known to the NIMC.
2. Relying Party (RP) must be registered with the NIMC, by visiting a dedicated self-service portal, register, submit relevant statutory documents and be issued a set of credentials. The RP must also purchase verification credits in advance.
Please see the Pricing List Page for further details.
| Component | Delivery Medium | Usage | Example |
|---|---|---|---|
| EnterpriseID (long) | QR Code | To be scanned by the Issuer with the NIMC MobileID | s.0YHcnxtptyYWvjNuYFKpJpKF |
| EnterpriseID (short) | USSD | To be entered manually as a part of a USSD string for feature phones | 260768 |
This is regardless of whether or not they are offering verifications as a direct service or not.
The Human Resources Department of an Oil and Gas company, for example, may wish to verify the Identity of its existing staff. They may employ the services of a Verification Agent or have the wherewithal to connect to NIMC directly. In either case, they must have a suite of credentials to verify the Identity of a NIN holder as an Enterprise.
- Like the Issuer, an Agent must be in possession of an active NIN, must have downloaded the NIMC MobileID Application and be in possession of their UserID (hereinafter known as the AgentID). Internet access is required.
In the diagram above, ABCDEF-1234 and UVWXZY-9671 are employees of the RP. Either person initiates the verification of a Virtual NIN that has been issued to the Enterprise (using either their Long ID or Short ID).
The request goes directly to the NIMC and the PII of the Virtual NIN Issuer is encrypted using the public key issued to the RP.
Once the encrypted payload is delivered to the RP (via an API callback), the API uses the private key of the RP to decrypt the payload before the PII can be utilised.
The Raw NIN IS NEVER shared with the RP and/or Agent and will no longer be a part of any payload.
Integrators and developers are encouraged to modify their databases to accomodate the new Virtual NIN format and expunge any NINs that have been associated with the ID Holder. The bearest minimal dataset may be stored, including the person’s firstname, middlename, surname and photo. All other information MUST come from the NIMC at the time of verification and MAY NOT be persisted in a local database of any description.
The diagram above assumes there is a Relying Party and an Integrator in the flow.
The Integrator offers Verification Services to the Relying Party, who in turn is not connected directly to the NIMC.
This flow recognises existing designs but requires everyone in the value chain to be identified by the NIMC. Natural Persons must have UserIDs, Relying Parties and Integrators alike, must have EnterpriseIDs.
¶ Typical Constraints - Data Privacy Enhancements
A Virtual NIN issued:
- by Person B, cannot be transferred to Person A
- by Person A for Enterprise B, cannot be used by Enterprise A
- to Enterprise A can be used only by Enterprise A and its satellites during the lifecycle of the token
- can be used ONCE only, may be persisted in a database and has a time-to-live of 72 hours by default.
¶ References
- Tokenization of iCloud email addresses
- GDPR in the EU and Tokenized Data
- Pseudonymization vs. Anonymization
- GDPR Encryption & Tokenization
- McAfee Security Awareness: Encryption vs Tokenization
- Very Good Security
- Thales: What is Tokenization?
- World Bank ID4D Tokenization