2. Functional View¶
2.1. Building Blocks: Standardized Definition and Scope¶
OSIA provides seamless interconnection between multiple building blocks part of the identity ecosystem. The building blocks are defined as follows:
The Enrollment component.
Enrollment is defined as a system to register biographic and/or biometric data of individuals. It is composed of enrollment client and server.
The Population Registry (PR) component.
PR is defined as “an individualized data system, that is, a mechanism of continuous recording, or of coordinated linkage, of selected information pertaining to each member of the resident population of a country in such a way to provide the possibility of determining up-to-date information concerning the size and characteristics of that population at selected time intervals. The population register is the product of a continuous process, in which notifications of certain events, which may have been recorded originally in different administrative systems, are automatically linked on a current basis. A. method and sources of updating should cover all changes so that the characteristics of individuals in the register remain current. Because of the nature of a population register, its organization, and also its operation, must have a legal basis.” 1
The UIN Generator component.
UIN generator is defined as a system to generate and manage unique identifiers.
The Automated Biometric Identification System (ABIS) component.
ABIS is defined as a system to detect the identity of an individual when it is unknown, or to verify the individual’s identity when it is provided, through biometrics.
The Civil Registry (CR) component.
CR is defined as “the continuous, permanent, compulsory and universal recording of the occurrence and characteristics of vital events pertaining to the population, as provided through decree or regulation is accordance with the legal requirement in each country. Civil registration is carried out primarily for the purpose of establishing the documents provided by the law.” 2
The Credential Management System (CMS) component.
CMS is defined as a system to manage the production, issuance and lifecycle management of credentials such as ID Cards, passports, driving licenses, digital ID/DTC/driving license, etc. It does not manage the usage of the issued credentials and related user account data (see Identity Provider)
The Third Party Services component.
Third Party Services is defined as a system that interfaces with external components that need to leverage identity databases for verification purposes. It provides services to biometrically authenticate, identify, and access identity attributes for use cases such as Know Your Customer (KYC).
The Identity Provider building block.
Identity Provider is defined as a system that creates, maintains, and manages credentials e.g. login/password and provides authentication services to relying applications within a federation or distributed network. Identity providers offer user authentication as a service.
The Digital Credential Issuance & Distribution System.
Digital Credential Issuance & Distribution System is defined as a system in charge of the issuance and delivery of the digital credentials built within the identity databases under the control of the CMS.
Note
Unlike all the rest of the building blocks, the Identity Provider building block is not expected to implement OSIA interfaces but rather to consume them.
Note
Digital Credential Issuance & Distribution System building block is out of scope for the current version of OSIA specification v6.1.0.
The building blocks are represented on the following diagram:
For more information on the functionalities for each building block and on the interfaces that each building block is recommended to implement, please refer to chapter 6 – Building blocks.
2.2. Interfaces¶
This chapter describes the following interfaces:
Notification
A set of services to manage notifications for different types of events as for instance birth and death.
Data access
A set of services to access data.
The design is based on the following assumptions:
All persons recorded in a registry have a UIN that is considered a key to access the person’s data for all records. Please note that the UIN does not have to be the same throughout all registries (see Chapter 3 - Security & Privacy for more information).
The registries (civil, population, or other) are considered as centralized systems that are connected. If one registry is architectured in a decentralized way, one of its component must be centralized, connected to the network, and in charge of the exchanges with the other registries.
Since the registries are customized for each business needs, dictionaries must be explicitly defined to describe the attributes, the event types, and the document types. See Data Access for samples of those dictionaries.
The relationship parent/child is not mandatory in the population registry. A population registry implementation may manage this relationship or may ignore it and rely on the civil registry to manage it.
All persons are stored in the population registry. There is no record in the civil registry that is not also in the population registry.
UIN Management
A set of services to manage the unique identifier.
Enrollment Services
A set of services to manage biographic and biometric data upon collection.
Population Registry Services
A set of services to manage a registry of the population.
Biometrics
A set of services to manage biometric data and databases.
Credential Services
A set of services to manage credentials, physical and digital.
ID Usage
A set of services implemented on top of identity systems to favour third parties consumption of identity data.
The following table describes in detail the interfaces and associated services.
Services |
Description |
---|---|
Notification |
|
Subscribe |
Subscribe a URL to receive notifications sent to one topic |
List Subscription |
Get the list of all the subscriptions registered in the server |
Unsubscribe |
Unsubscribe a URL from the list of receiver for one topic |
Confirm |
Confirm that the URL used during the subscription is valid |
Create Topic |
Create a new topic |
List Topics |
List all the existing topics |
Delete Topic |
Delete a topic |
Publish |
Publish an event to all systems that have subscribed to this topic |
Notify |
Callback registered during subscription and called when an event is published |
Data Access |
|
Read Person Attributes |
Read person attributes |
Match Person Attributes |
Check the value of attributes without exposing private data |
Verify Person Attributes |
Evaluate simple expressions on person’s attributes without exposing private data |
Query Person UIN |
Query the persons by a set of attributes, used when the UIN is unknown |
Query Person List |
Query the persons by a list of attributes and their values |
Read document |
Read in a selected format (PDF, image, etc.) a document such as a marriage certificate |
UIN Management |
|
Generate UIN |
Generate a new UIN |
Enrollment Services |
|
Create Enrollment |
Insert a new enrollment |
Read Enrollment |
Retrieve an enrollment |
Update Enrollment |
Update an enrollment |
Partial Update Enrollment |
Update part of an enrollment |
Finalize Enrollment |
Finalize an enrollment (mark it as completed) |
Delete Enrollment |
Delete an enrollment |
Find Enrollments |
Retrieve a list of enrollments which match passed in search criteria |
Send Buffer |
Send a buffer (image, etc.) |
Get Buffer |
Get a buffer |
Population Registry Services |
|
Find Persons |
Query for persons, using all the available identities |
Create Person |
Create a new person |
Read Person |
Read the attributes of a person |
Update Person |
Update a person |
Delete Person |
Delete a person and all its identities |
Merge Persons |
Merge two persons |
Move Identity |
Move one identity from one person to another one |
Create Identity |
Create a new identity in a person |
Read Identity |
Read one or all the identities of one person |
Update Identity |
Update an identity. An identity can be updated only in the status claimed |
Partial Update Identity |
Update part of an identity. Not all attributes are mandatory. |
Delete Identity |
Delete an identity |
Set Identity Status |
Set an identity status |
Define Reference |
Define the reference identity of one person |
Read Reference |
Read the reference identity of one person |
Read Galleries |
Read the ID of all the galleries |
Read Gallery Content |
Read the content of one gallery, i.e. the IDs of all the records linked to this gallery |
Biometrics |
|
Create Encounter |
Create a new encounter. No identify is performed |
Read Encounter |
Read the data of an encounter |
Update Encounter |
Update an encounter |
Delete Encounter |
Delete an encounter |
Merge Encounters |
Merge two sets of encounters |
Move Encounter |
Move one encounter from one person to another one |
Update Encounter Status |
Set an encounter status |
Update Encounter Galleries |
Set the galleries of an encounter |
Read Template |
Read the generated template |
Read Galleries |
Read the ID of all the galleries |
Read Gallery content |
Read the content of one gallery, i.e. the IDs of all the records linked to this gallery |
Identify |
Identify a person using biometrics data and filters on biographic or contextual data |
Verify |
Verify an identity using biometrics data |
Credential Services |
|
Create Credential Request |
Request issuance of a secure credential |
Read Credential Request |
Retrieve the data/status of a credential request |
Update Credential Request |
Update the requested issuance of a secure credential |
Cancel Credential Request |
Cancel the requested issuance of a secure credential |
Find Credentials |
Retrieve a list of credentials that match the passed in search criteria |
Read Credential |
Retrieve the attributes/status of an issued credential (smart card, mobile, passport, etc.) |
Suspend Credential |
Suspend an issued credential. For electronic credentials this will suspend any PKI certificates that are present |
Unsuspend Credential |
Unsuspend an issued credential. For electronic credentials this will unsuspend any PKI certificates that are present |
Revoke Credential |
Revoke an issued credential. For electronic credentials this will revoke any PKI certificates that are present |
Set Credential Status |
Change the credential status |
Find Credential Profiles |
Retrieve a list of credential profils that match the passed in search criteria |
ID Usage |
|
Verify ID |
Verify Identity based on UIN and set of attributes (biometric data, demographics, credential) |
Identify |
Identify a person based on a set of attributes (biometric data, demographics, credential) |
Read Attributes |
Read person attributes |
Read Attributes set |
Read person attributes corresponding to a predefined set name |
2.3. Use Cases - How to Use OSIA¶
Below are a set of examples of how OSIA interfaces could be implemented in various use cases.
2.3.1. Birth Use Case¶
Checks
When a request is submitted, the CR may run checks against the data available in the PR using:
matchPersonAttributes
: to check the exactitude of the parents’ attributes as known in the PRreadPersonAttributes
: to get missing data about the parents’s identityqureyPersonUIN
: to check if the new born is already known to PR or not
How the CR will process the request in case of data discrepancy is specific to each CR implementation and not in the scope of this document.
Creation
The first step after the checks is to generate a new UIN. To do so, the CR requests a new UIN to the PR using generateUIN service. At this point the birth registration takes place. How the CR will process the birth registration is specific to each CR implementation and not in the scope of this document.
Notification
As part of the birth registration, it is the responsibility of the CR to notify other systems, including the PR, of this event using:
publish
: to send a birth along with the newUIN
.
The PR, upon reception of the birth event, will update the identity registry with this new identity using:
readPersonAttributes
: to get the attributes of interest to the PR for the parents if relevant and the new child.
2.3.2. Death Use Case¶
Subject identification checks
When a death notification is submitted by an authorized party, the CR shall run checks against the data available in the PR using:
matchPersonAttributes
: to check the exactitude of the subject’s attributes as known in the PRreadPersonAttributes
: to get missing data about the subject’s identity thatqueryPersonUIN
: to check if the person is already known to PR or not
How the CR will process the request in case of data discrepancy is specific to each CR implementation and not in the scope of this document. The CR may implement an internal procedure to create a valid PR record retrospectively.
Notification creation
The first step after the identity checks is to notify the life event status to the PR based on an identified record. At this point the death notification is recorded by not finally registered. Most states implement a waiting period. How the CR will process the death notification is specific to each CR implementation - a provisional certificate is possible.
Final registration
When the PR finalizes the status of the subject’s person record then the CR may publish this information at its discretion. The PR may maintain a list of interested parties who shall be informed of any finalized death status. A final certificate of death including the context of this event is typically issued by the CR to the notifier for distribution.
2.3.3. Deduplication Use Case¶
During the lifetime of a registry, it is possible that duplicates are detected. This can happen for instance after the addition of biometrics in the system. When a registry considers that two records are actually the same and decides to merge them, a notification must be sent.
How the target of the notification should react is specific to each subsystem.
2.3.4. ID Card Request Use Case (1)¶
An ID card is one type of credential. The procedures surrounding credential issuance may involve several sub-systems that contribute to the establishment of the applicant identity and the required data for the type of credential.
This use case assumes a simple starting scenario where the identity is known and can be validated, mostly with data available from a Civil or Population Registry based Identity Provider. These use cases also assume the use of a Credentials Management System (CMS) responsible for the technical personalization and lifecycle management of a credential such as an ID card.
The use case aims to show how a selection of the CMS API calls can support a typical, use case in relation to CMS usage.
Identity Checks
The example scenario assumes a credential provider service such as an ID card provider (National ID, Voter, &c). Such as service may access several OSIA API based components to establish an ID check. In this example the Population Register is used. This example case also assumes that the credential provider holds its own register of credentials issued to its subscribers.
Suspend Credential
In the example above the citizen has lost a card and requests a replacement. The credential provider service first establishes the legitimacy of the citizen identity and the identity of the lost document within its own register. The next likely step in such a use case is to suspend the current credential. This is done using a CMS API call. The CMS confirms this step with a reference. In some use cases the reported lost credential may be cancelled immediately, but this is typically a decision made by the policy of the credential provider. There is an OSIA API call to both either or both requirements to the CMS.
Requesting a New Credential
The credential provider is in this example case responsible for preparing the core document data for the CMS. The CMS itself may further process this data appropriate to the credential type: for example the CMS may be the service that signs this document data electronically. The CMS returns a new request ID to the credential provider service which will enable the provider to query credential production status within the CMS domain.
Such a business process might be interrupted by an new event such as the citizen finding her lost card and wishing to cancel the replacement order, perhaps to avoid a replacement fee. Depending on the status returned by the CMS to the credential provider then the credential provider service will act accordingly in informing the citizen whether this is possible. In this case the citizen’s card was already replaced by the CMS so the original card is now cancelled.
The CMS on its side is responsible for maintaining a credential profile which can be accessed by the CR at a later point. This use case stops for CMS when the card is distributed to the CR for collection by the citizen.
2.3.5. ID Card Request Use Case (2)¶
A second ID Request use case shows how the CMS might expose more decisions to the credential providing service. In this case it is the citizen facing provider that controls the cancellation of the lost document, and this is not automated within the CMS component.
This second example shows how APIs may be used to flex the control over functions such as credential lifecycle management. This example first makes use of the API to suspend a credential pending production of a replacement; then a second API call is made to the CMS to instruct cancellation of the lost document.
2.3.6. Credentials Issuance Use Case¶
This use case describes an example of interaction between the different OSIA components to capture identity data, generate a UIN, process the identity data and issue both a physical and digital credential.
This use case also demonstrates what a middleware could do when connected to multiple OSIA compatible systems. In this example the middleware is acting as an enrollment server, scheduling all the processing when the data collection is finalized.
This use case was implemented for demonstrating OSIA and is presented in this video.
The main steps are:
The citizen interacts with the enrollment station to provide the biographic data, the supporting document images, a portrait and a set of fingerprints.
When all the data is collected, the full data set if pushed to the middleware using the OSIA
createEnrollment
service.Backend processing includes:
interactions with the population registry to generate a UIN and insert the collected data,
interaction with the ABIS to insert the face and fingerprints,
interactions with multiple Credential Management System to request the issuance of different types of credentials.
2.3.7. Bank account opening Use Case¶
2.3.8. Police identity control Use Case¶
2.3.9. Telco Customer Enrollment with ID document¶
Use case objective
This use case allows a telco operator to check a citizen’s ID document and identity.
The use case relies on an IDMS to check the authenticity and validity of the ID document presented by the citizen, then to check that he actually is the holder of the document.
Pre-conditions
The citizen is registered in the IDMS and has a UIN.
The citizen has a valid ID document.
The citizen presents as a customer to the agent.
The IDMS should support authentication token generation to protect against misusage of UIN.
Use case description
The customer shows his ID document to the Agent. The Agent inputs (possibly by reading an MRZ on the document) the UIN, document ID, name, given name, DOB, and a live facial portrait taken of the citizen.
The telco server calls an IDMS API to check if the information of the ID document is coherent and if the document is still valid.
The telco server calls an IDMS API to get meta data of the document such as the issuing agency, the issuing date, expiration date, etc.
The telco server calls an IDMS API to check if the customer is actually the holder of the document using his live biometric portrait.
The telco server calls an IDMS API to get some reliable data of the customer in order to register him.
Result
The citizen is now identified, authenticated and registered in a customer database and becomes eligible to buy a SIM card.
The telco operator can prove regulatory controls have been applied for ‘Know Your Customer’ compliance.
2.3.10. Telco Customer Enrollment with no ID document¶
A customer applying for a new network SIM card may not be able to present an ID document as part of her application.
Use case objective
This use case allows a telco operator to check a citizen’s identity and get his attributes relying on IDMS to check that the biometrics of the citizen matches with his UIN.
Pre-conditions
The citizen is registered in the IDMS and has a UIN.
The citizen biometrics are registered and associated to his UIN.
The citizen presents as a customer to the agent.
The IDMS should support authentication token generation to protect against misusage of UIN.
Use case description
The Agent inputs the citizen’s UIN, Name, 1st Name, DOB and takes a live photo portrait of the customer.
The telco server calls an IDMS API to check if the customer is actually the citizen corresponding to the given UIN thanks to his live portrait (face biometric matching).
The telco server calls an IDMS API to get some reliable data of the customer in order to register him.
Result
The citizen is now identified, authenticated and registered in a customer database and becomes eligible to buy a SIM card.
The telco operator can prove regulatory controls have been applied for ‘Know Your Customer’ compliance.
Footnotes
- 1
Handbook on Civil Registration and Vital Statistics Systems: Management, Operation and Maintenance, Revision 1, United Nations, New York, 2018, available at: https://unstats.un.org/unsd/demographic-social/Standards-and-Methods/files/Handbooks/crvs/crvs-mgt-E.pdf , para 65.
- 2
Principles and Recommendations for a Vital Statistics System, United Nations publication Sales Number E.13.XVII.10, New York, 2014, paragraph 279