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:

Fig. 2.1 Building Blocks identified as part of the identity ecosystem

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:

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Table 2.1 Interfaces List

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

Fig. 2.2 Birth Use Case

1. 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 PR

   • readPersonAttributes: to get missing data about the parents’s identity

   • qureyPersonUIN: 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.

2. 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.

3. 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 new UIN.

   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

Fig. 2.3 Death Use Case

1. 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 PR

   • readPersonAttributes: to get missing data about the subject’s identity that

   • queryPersonUIN: 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.

2. 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.

3. 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.

Fig. 2.4 Deduplication Use Case

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.

Fig. 2.5 ID Card Request Use Case (1)

1. 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.

2. 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.

3. 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.

Fig. 2.6 ID Card Request Use Case (2)

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.

Fig. 2.7 Credentials Issuance Use Case

The main steps are:

1. The citizen interacts with the enrollment station to provide the biographic data, the supporting document images, a portrait and a set of fingerprints.

2. When all the data is collected, the full data set if pushed to the middleware using the OSIA createEnrollment service.

3. 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

Fig. 2.8 Bank account opening Use Case

2.3.8. Police identity control Use Case

Fig. 2.9 Collaborative identity control

2.3.9. Telco Customer Enrollment with ID document

Fig. 2.10 Telco Customer Enrollment with ID document

1. 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.

2. 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.

3. 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.

4. 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.

Fig. 2.11 Telco Customer Enrollment with no ID document

1. 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.

2. 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.

3. 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.

4. 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