Tag: 169 (identity-data)
Data Item: JSON Object
Semantics: Identity Data of a Person in QR-Code
Point of Contact: Resham Chugani (resham@mosip.io)
IANA Registration: IANA CWT Registry (Search Key: 169)
Version: 1.0.0
This document specifies a generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).
Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.
Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.
For instance, in a cross-border scenario, remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a standard QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.
Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.
To tackle the aforementioned challenge, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. This approach also helps enhance interoperability. Note: It is essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.
Claim 169 represents a JSON Object that includes the following ID attributes, as outlined in the table. You can find an illustration of the ID structure contained within Claim 169, as stated below:
Note: All the fields here are optional.
1
tstr
ID
Unique ID to indicate the PII data
2
tstr
Version
Version of the ID data
3
tstr
Language
Language used in other attributes
4
tstr
Full Name
Full name of the person
5
tstr
First Name
First name of the person
6
tstr
Middle Name
Middle name of the person
7
tstr
Last Name
Last name of the person
8
tstr
Date of Birth
Date of birth in YYYYMMDD format
9
tstr
Gender
Gender with the following values: 1 - Male, 2 - Female, 3 - Others
10
tstr
Address
Address of the person - Separator character \n
11
tstr
Email ID
Email id of the person
12
tstr
Phone Number
Contact number of the person
13
tstr
Nationality
Nationality of the person
14
int
Marital Status
Marital status - Can contain the following values: 1 - Unmarried, 2 - Married, 3 - Divorced
15
tstr
Guardian
Name/id of the entity playing the role of a guardian, such as a mother, father, spouse, sister, legal guardian etc.
16
tstr
Binary Image
Binary image of the person's photograph
17
int
Binary Image Format
Binary image format. Can contain the following values 1 - JPEG, 2 - JPEG2, 3 - AVIF, 4- WEBP
18
[int]
Best Quality Fingers
An unsigned 8-bit number encoding the hand position of the finger. It must be in the range 0-10, where 0 represents "Unknown", 1-5 represents right thumb to little finger, and 6-10 represents left thumb to little finger in sequence
19.. 99
tstr
Reserved
Reserved for future attributes
Claim Name: identity-data
Claim Description: Registering the claim for storing identity data of a person, which could be personally identifiable data (PII) mostly used in Foundational/National ID for cross-border interoperability.
Claim Key: 169
Claim Value Type(s): map
Change Controller: MOSIP
Specification Document(s): Section 3, Section 4
[1] C. Bormann, and P. Hoffman. "Concise Binary Object Representation (CBOR)". RFC 7049, October 2013.
[2] Mike Jones, Hannes Tschofenig, Ludwig Seitz "CBOR Web Token (CWT)". RFC 8392, March 2018.
Mahammed Taheer (mohd.taheer@gmail.com)
Resham Chugani (resham@mosip.io)
Rounak Nayak (rounak@ooru.io)
Sasikumar G (sasi@duck.com)
Sreenadh S (sreeavtar@gmail.com)
MOSIP is built on a modular, microservices-based architecture. Its modularity enables seamless adoption even in complex scenarios. Most MOSIP modules are designed as robust foundational infrastructure components, making them suitable for integration into various projects.
MOSIP is designed with the following architectural principles. These architecture principles are core to the development of the system's features and have a great influence on how and why specific software design patterns are used within.
Data Privacy
No Vendor Lock-in
Open Standards
Async/ Offline First
Commodity Computing
Fault tolerant
Manageable
Secure By Default
The diagram below provides an architectural overview, visually representing the components of the MOSIP Identity framework and its associated technology stack.
This reference blueprint provides a comprehensive vision for designing and implementing a Digital ID-led DPI infrastructure. It outlines how foundational identity systems can be leveraged alongside key DPI components, enabling various use cases across both the public and private sectors. The blueprint is structured in layers of technology, governance, and service delivery, ensuring scalability, inclusivity, and compliance with legal frameworks.
Below is an explanation of its core components and their roles within the ecosystem.
At the core of the system is the Unique Digital Identity, which establishes a singular, definitive identity for every individual. This digital identity forms the backbone of all operations, ensuring secure identification and verification across diverse domains.
The ID Project Custodian, whether a designated authority, ministry, or department, oversees this infrastructure. This custodian is crucial for maintaining governance, regulatory compliance, and operational efficiency, ensuring that all identity services align with national policies and frameworks.
Supporting the ecosystem is a robust Infrastructure Layer, consisting of cloud infrastructure and connectivity. The cloud ensures scalability, resilience, and the ability to manage large volumes of identity data. The connectivity layer ensures the system's accessibility, making it functional in both urban and remote areas.
At the heart of the blueprint is the Foundational ID Platform, a centralized framework for issuing and managing foundational IDs. This platform underpins all identity-related services, ensuring secure identity handling and enabling core functions like registration, lifecycle management, verification, authentication, and e-KYC (Electronic Know Your Customer). These services are essential for building trusted interactions across all sectors.
Now that we have established the core layers to anchor trust, we can expand functionality through augmented services, such as eSignature capabilities. These enable secure digital transactions and help governments transition from traditional in-person signatures. These added features enhance the system's utility, which is especially crucial for enabling paperless workflows.
To ensure widespread adoption and accessibility, the system features a Multi-Channel Access Layer that enables interaction through web, mobile (Apps, USSD), and physical interfaces(QR). This design ensures inclusivity by accommodating individuals with diverse backgrounds and varying levels of technological proficiency, to interact with the system effortlessly.
In addition to its core and augmented services, consent management and data exchange capabilities are crucial for advancing digitization and digital development. These capabilities facilitate the regulated sharing of information across both public and private platforms. Moreover, the integration of payment systems adds significant value to Government-to-People (G2P) use cases. Additionally, data exchange can be further enhanced through the use of Verifiable Credentials.
This blueprint is designed to act as a catalyst for seamless service delivery and impactful use cases across both the private and public sectors. It is essential to involve the private sector in the digitization process, as it plays a key role in enabling services such as banking, e-commerce, and telecommunications, thereby streamlining operations. In the public sector, this blueprint enhances service delivery in areas like social welfare, healthcare, taxation, and education, contributing to better governance and increased citizen engagement. By adopting an overall ID-led approach, it not only accelerates the adoption of digital identity but also ensures improved governance, streamlined operations, and enhanced citizen participation.
Finally, the framework operates within a robust legal and regulatory environment, complying with key legislation such as the Data Protection Act, the Cybersecurity Act, and the Electronic Transactions Act. These laws safeguard data privacy and security, ensuring that the system operates transparently, trustworthy, and in full legal compliance.
To know how MOSIP can be deployed, refer to Getting Started. The different installation models are detailed in the Deployment section.
Digital Identification is a means of identifying 'who you are' through some kind of digital medium. The digital medium could be any device such as a mobile phone or a computer or anything that has a digital means of identifying 'who you are' in both offline and online mode with your consent irrespective of your religion, caste, creed, gender, country and ethnicity. The Internet is only an enabler but is not the mandatory requirement for digital identification. While identifying 'who you are', the user bearing the identity must have absolute control of revealing a controlled set of information that they wish to reveal and not everything in order to become eligible for getting a service rendered.
Governments are exploring the development of multipurpose foundational ID systems, in which individuals receive a unique identifier from the government that they can use for identity assertion and verification. It can then be used to access a wide variety of government and private services.
Functional IDs are the IDs that are used in specific use cases. By design, they are created having the final usecase in mind such as healthcare, finance, banking, insurance, social and civil registry etc. The Functional ID systems can leverage the Foundational ID system.
MOSIP is a robust, secure, open-source platform for building foundational identity systems. MOSIP is configurable and flexible to adapt to a country’s national ID requirements.
MOSIP needs to work along with other ecosystem players to create a solution for a particular country.
Key MOSIP offerings are:
ID Lifecycle Management
ID Authentication
National ID systems can leverage MOSIP as the base platform and configure, customize, and extend it to build systems just the way needed. The image below depicts how MOSIP provides the base layer to build a national ID platform.
This page lists the standards and specifications published by MOSIP which are as below:
Tag: 169 (identity-data)
Data Item: JSON Object
Semantics: Identity Data of a Person in QR-Code
Point of Contact: Resham Chugani (resham@mosip.io)
IANA Registration: IANA CWT Registry (Search Key: 169)
Version: 1.1.0
This document specifies an updated version of the generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).
Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.
Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.
For instance, in a cross-border scenario remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.
Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.
To tackle the challenge above, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. However, it's essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.
Claim 169 represents a JSON Object that includes the below table as ID attributes. You can find an illustration of the ID structure contained within Claim 169, where:
All the fields here are OPTIONAL.
1
tstr
ID
Unique ID to indicate the PII data
2
tstr
Version
Version of the ID data
3
tstr
Language
Language used in other attributes
4
tstr
Full Name
Full name of the person
5
tstr
First Name
First name of the person
6
tstr
Middle Name
Middle name of the person
7
tstr
Last Name
Last name of the person
8
tstr
Date of Birth
Date of birth in YYYYMMDD format
9
int
Gender
Gender with the following values 1 - Male, 2 - Female, 3 - Others
10
tstr
Address
Address of the person, separator character \n
11
tstr
Email ID
Email id of the person
12
tstr
Phone Number
Contact number of the person
13
tstr
Nationality
Nationality of the person
14
int
Marital Status
Marital status - Can contain the following values 1 - Unmarried, 2 - Married, 3 - Divorced
15
tstr
Guardian
Name/id of the entity playing the role of a guardian, such as a mother, father, spouse, sister, legal guardian etc.
16
tstr
Binary Image
Binary image of the person's photograph
17
int
Binary Image Format
Binary image format. Can contain the following values 1 - JPEG, 2 - JPEG2, 3 - AVIF, 4 - WEBP
18
[int]
Best Quality Fingers
An unsigned 8-bit number encoding the hand position of the finger. It must be in the range 0-10, where 0 represents "Unknown", 1-5 represents right thumb to little finger, and 6-10 represents left thumb to little finger in sequence
19.. 49
Reserved
Reserved for future attributes
50.. 74
Reserved
Reserved for Person's Biometrics Data attributes
50
[Biometrics]
Right Thumb
Person's Right Thumb biometrics
51
[Biometrics]
Right Pointer Finger
Person's Right Pointer Finger biometrics
52
[Biometrics]
Right Middle Finger
Person's Right Middle Finger biometrics
53
[Biometrics]
Right Ring Finger
Person's Right Ring Finger biometrics
54
[Biometrics]
Right Little Finger
Person's Right Little Finger biometrics
55
[Biometrics]
Left Thumb
Person's Left Thumb biometrics
56
[Biometrics]
Left Pointer Finger
Person's Left Pointer Finger biometrics
57
[Biometrics]
Left Middle Finger
Person's Left Middle Finger biometrics
58
[Biometrics]
Left Ring Finger
Person's Left Ring Finger biometrics
59
[Biometrics]
Left Little Finger
Person's Left Little Finger biometrics
60
[Biometrics]
Right Iris
Person's Right Iris biometrics
61
[Biometrics]
Left Iris
Person's Left Iris biometrics
62
[Biometrics]
Face
Person's Face biometrics
63
[Biometrics]
Right Palm Print
Person's Right Palm Print biometrics
64
[Biometrics]
Left Palm Print
Person's Left Palm Print biometrics
65
[Biometrics]
Voice
Person's Voice biometrics
66.. 74
Reserved
Reserved for future for Person's Biometrics Data attributes
75.. 99
Reserved
Reserved for future attributes
0
bstr
Data
Biometrics binary data
1
int
Optional biometrics data format
2
int
Optional biometrics data sub format
3
tstr
Data issuer
Optional biometric data issuer
0
Image
1
Template
2
Sound
3
Bio hash
Image
0
PNG
1
JPEG
2
JPEG2000
3
AVIF
4
WEBP
5
TIFF
6
WSQ
100..200
Vendor specific
Template
0
Fingerprint Template ANSI 378
1
Fingerprint Template ISO 19794-2
2
Fingerprint Template NIST
100..200
Vendor specific
Sound
0
WAV
1
MP3
TODO:
Current map structure is in plain text and its not the recommended way to handle privacy. Adoption of SD-JWT or equivalent can be considered.
CWT MUST be signed, create a COSE_Sign/COSE_Sign1 object using the Message as the COSE_Sign/COSE_Sign1 Payload; all steps specified in RFC8152 for creating a COSE_Sign/COSE_Sign1 object MUST be followed.
If the CWT is a COSE_Encrypt/COSE_Encrypt0 object,create a COSE_Encrypt/COSE_Encrypt0 using the Message as the plaintext for the COSE_Encrypt/COSE_Encrypt0 object; all steps specified in RFC8152 for creating a COSE_Encrypt/COSE_Encrypt0 object MUST be followed.
To verify the claims the CWT is a COSE_Sign/COSE_Sign1, follow the steps specified in Section 4 of RFC8152 ("Signing Objects") for validating a COSE_Sign/COSE_Sign1 object. Let the Message be the COSE_Sign/COSE_Sign1 payload. Once signature is valid we SHOULD validate the public key against a preconfigured key. In case encrypted Else, if the CWT is a COSE_Encrypt/COSE_Encrypt0 object, follow the steps specified in Section 5 of [RFC8152] ("Encryption Objects") for validating a COSE_Encrypt/COSE_Encrypt0 object. Let the Message be the resulting plaintext.
The security of the CWT relies upon on the protections offered by COSE. Unless the claims in a CWT are protected, an adversary can modify, add, or remove claims.
Since the claims conveyed in a CWT is used to make identity claim decisions, it is not only important to protect the CWT but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT. Without trust of the recipient in the party that created the CWT, no sensible identity verification can be made. Furthermore, the creator of the CWT needs to carefully evaluate each claim value prior to including it in the CWT so that the recipient can be assured of the validity of the information provided.
Syntactically, the signing and encryption operations for Nested CWTs may be applied in any order; however, if encryption is necessary, producers normally should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
IANA is requested to register the revised specifications of claim 169 in "CBOR Web Token (CWT) Claims" registry IANA CWT Claims.
Claim Name: identity-data Claim Description: Registering the claim for storing identity data of a person, which could be Personally Identifiable Data (PII) mostly used in Foundational/National ID for cross-border interoperability. Claim Key: 169 Claim Value Type(s): map Change Controller: MOSIP Specification Document(s): Section 3, Section 4
This work is the result of the dedicated efforts of contributors who recognize the critical importance of interoperability and a consistent QR code specification. The revised version has been shaped significantly by the input of our working group committee, comprising members from the following organizations: GetGroup, PWC and Tech 5.
We extend our gratitude to the committee members for their invaluable time and insights throughout the evaluation phase.
GetGroup: Aiman Tarek
PWC: Chaitanya Giri
Tech 5: Bejoy Ak, Nelson Branco, Rahul Parthe
MOSIP: Harini Sampathkumar, Janardhan BS, Mahammed Taheer, Ramesh Narayanan, Resham Chugani, Reeba Thomas, Sanchi Singh, Sasikumar Ganesan, Sreenadh S, Swati Goel, Vishwanath V
Mahammed Taheer (mohd.taheer@gmail.com)
Resham Chugani (resham@mosip.io)
Rounak Nayak (rounak@ooru.io)
Sasikumar G (sasi@duck.com)
Sreenadh S (sreeavtar@gmail.com)
