6 Functional Requirements
This section lists the technical capabilities of this Building Block.
Internal functional components
A common set of unique internal functional components are required to orchestrate the services of the Scheduler Building Block as shown below. The REST API's interfaces route service requests to/from external Building Blocks and appropriate internal blocks in appropriate formats. A brief description of the generic functionality of each of these components has been given below from a minimum viable product perspective. Detailed design and feature lists of these blocks can be customized by developers to optimally match specific target implementation needs.
6.1 Identity Usage
Identity Building Block must offer an API to verify Identities following a Gov Stack recommended Open Standard API. (REQUIRED)
Identity Building Block must offer an API to Verify Identity of an individual based on one of its known identifiers. (REQUIRED)
Identity Building Block must offer an API to retrieve personal attributes of an individual from one of its identifiers. To be noted that this service will be subject to preliminary access granted by the system and by the individual (informed consent). Authorized access control should be part of API as opposed to external configuration alone. This ensures that relying parties are verified by the API before sharing sensitive data. (REQUIRED)
Identity Building Block must offer an API to identify an unknown individual, which means retrieve an identity identifier from a set of personal attributes sent. This service is normally to be used for security/law enforcement purposes and must be limited to registries of wanted people. For privacy and security reasons, this feature should only be considered where clear and accountable security/law enforcement rules are in place. (REQUIRED)
Identity Building Block must offer an API to verify one characteristic of an individual without having to disclose actually the recorded related attributes. The typical request response is Yes or No (sample use case: age verification, is a person older than 18 > Yes to No). (REQUIRED)
Identity Building Block must offer Identity Verification services based on modalities listed below following a GovStack recommended Open Standard API. (REQUIRED)
6.1.1 Modalities
Identity verification can be performed in several ways and based on several modalities depending on various criteria.
For example, Identity verification will be performed according to the:
Context of identity verification: online, face-to-face by a third party, self-identity verification, in the absence of infrastructure and technologies.
Capacities given to the individual: having an ID Card, a person Identifier, a password or PIN code, using its biometrics, mobile subscription, or smartphone.
Status of the individual: can they read? Do they have usable fingerprints? Are they old enough to have an ID Card?
Level of trust required: according to the sensitivity of the operations, level of assurance required, policies established by the state or by the service provider, multiple factor identity verification.
Business constraints: does the use case require to be very fast, touchless, seamless, physical, or digital?
Local laws and regulations: the identity verification could differ according to local regulations and laws which may indicate specific ways to perform identity verification.
Below shown table will list the different modalities that can be used to perform an identity verification, the Identity Building Block may use any of them including a combination of several of them to verify a person's identity.
Capability | Description | Recommended Use | Level of Trust | Requirements for individual or for the Context of Use |
Login/ Password | Previously given login/password are typed in a login form to verify person identity. | For online access on web site or in mobile application. | Medium
(What you KNOW only) | Require the individual to have access to a digital device having network connectivity and sufficient power stability. |
Visual physical identity credential identity control | National ID card provided to the individual includes security features allowing to verify the document is genuine and data printed on it allow to know the identity of the individual. | For fast verification in public place, or when there is no digital identity verification available or no connectivity to network. | Low
(What you HAVE only) | Having been issued and delivered a physical identity credential. |
eID card identity data control | National ID card provided to the individual includes a chip in which its identity information is securely written allowing them to get them and make sure about their authenticity. | For identity verification in face to face control. | Medium
(What you HAVE only) | Having been issued and delivered a physical identity credential with a chip (eID card), having access to a digital identity verification device. No need for network connectivity. |
eID card based identity verification | National ID card provided to the individual includes a chip in which its identity information is securely written allowing them to get them and make sure about their authenticity. Those same data can be used for a match versus other information like who the person pretends to be, what is printed on the document or it’s biometrics captured live. | For identity verification in face to face control. | High
(What you HAVE and what you ARE) | Having been issued and delivered a physical identity credential with a chip (eID card), having access to a digital identity verification device which can perform a matching between person attributes and chip stored attributes.
|
Fingerprint 1:1 matching versus ID credential | The individual live capture fingerprint will be compared to its fingerprint(s) captured during its identity creation. Those original fingerprints being stored on or within its Identity credential. | For identity verification in face to face control or self-control of identity (i.e. airport eGates). | High
(What you ARE) | Having been issued and delivered a physical identity credential including a digital ID into a chip (eID card) or in a cryptogram, having access to a digital identity verification device which can perform an ID Credential reading, fingerprint(s) capture and matching with attributes stored in ID credential. |
Fingerprint 1:1 matching online | The individual live capture fingerprint will be compared to its fingerprint(s) captured during its identity creation. The fingerprints are verifiable using an online service. | For identity verification in face to face control or self-control of identity (ie airport eGates) | High
(What you ARE) | Having been registered to a state recognized identity provider, having access to a connected digital identity verification device which can perform fingerprint(s) capture and access to online identity verification services. |
Fingerprint recognition | The individual doesn't provide its identity, a search based on its fingerprints is performed against a database of known identities in order to identify him/her. | NOT RECOMMENDED FOR CIVIL USE. This capability is rather to be used for security purposes in criminal or border control systems or secured building access. | High
(What you ARE) | Having been registered (or not) to a state recognized identity database, having access to a connected digital identity verification device which can perform fingerprint(s) capture and access to online identification services. |
Facial 1:1 matching versus ID credential | The individual live face capture will be compared to its face captured during its identity creation. That original face capture may be stored on or within its Identity credential. | For identity verification in face to face control or self-control of identity (ie airport eGates) A face liveness detection is recommended. | High
(What you ARE) | Having been issued and delivered a physical identity credential including a digital ID into a chip (eID card) or in a cryptogram, having access to a digital identity verification device which can perform an ID Credential reading, face capture and matching with attributes stored in ID credential. |
Facial 1:1 matching online | The individual live face capture will be compared to its face captured during its identity creation. The face is verifiable using an online service. | For identity verification in face to face control or self-control of identity (ie airport eGates) A face liveness detection is recommended. | High
(What you ARE) | Having been registered to a state recognized identity provider, having access to a connected digital identity verification device which can perform face capture and access to online identity verification services. |
Facial recognition | The individual doesn't provide its identity, a search based on its face is performed against a database of known identities in order to identify him/her. | NOT RECOMMENDED FOR CIVIL USE. This capability is rather to be used for security purposes in criminal or border control systems or secured building access. | High
(What you ARE) | Having been registered (or not) to a state recognized identity database, having access to a connected digital identity verification device which can perform face capture and access to online identification services. |
Iris 1:1 matching versus ID credential | The individual live iris captured will be compared to its iris captured during its identity creation. That original iris capture may be stored on or within its Identity credential. | For identity verification in face to face control or self-control of identity (i.e. airport eGates) Liveness detection is recommended. | High
(What you ARE) | Having been issued and delivered a physical identity credential including a digital ID into a chip (eID card) or in a cryptogram, having access to a digital identity verification device which can perform an ID Credential reading, iris capture and matching with attributes stored in ID credential. |
Iris 1:1 matching online | The individual live iris capture will be compared to its iris captured during its identity creation. The iris is verifiable using an online service. | For identity verification in face to face control or self-control of identity (i.e. airport eGates) Liveness detection is recommended. | High
(What you ARE) | Having been registered to a state recognized identity provider, having access to a connected digital identity verification device which can perform iris capture and access to online identity verification services. |
Iris recognition | The individual doesn't provide its identity, a search based on its iris is performed against a database of known identities in order to identify him/her. | NOT RECOMMENDED FOR CIVIL USE. This capability is rather to be used for security purposes in criminal or border control systems or secured building access. | High
(What you ARE) | Having been registered (or not) to a state recognized identity provider, having access to a connected digital identity verification device which can perform iris capture and access to online identification services. |
OTP | The individual needs to type in a form (online or app) a One Time Password (OTP) received from the identity provider. | Can be used when needing to access an online service. To be used a second factor of authentication, for example with a login password). | High
(What you KNOW and what you HAVE) | Having been registered to a state recognized identity provider, owning a mobile subscription, being in capacity to receive messages (SMS, messaging, email), having access to service provider online services. It is important to acknowledge different patterns of phone ownership (individual, household, community). |
Online ID credential matching | The individual will authenticate versus himself its ID credential online. The process may include biometrics control versus data printed or stored in the Identity credential, together with genuity check of the document using security features and eventually control of document authenticity versus database of issued documents. | Can be used to perform remote on-boarding of persons in services. To be noted it anyway required a face to face on-boarding to enroll for the Identity credential. Ensuring the document is genuine can be a challenge, unless an ID credential secured chip is involved as part of the process. | High
(What you HAVE, what you ARE, what you WERE) | Owning an ID Credential registered for online services verification, having a connected smartphone eventually capable of reading a chip. |
Online PKI based identity verification | The individual uses its identity credential or a digital device to encrypt or sign identity verification data which can then be verified on server side. A PIN code is requested. | Can be used if ,and only if, a specific PKI infrastructure is in place to issue, read and verify online. | HIGH
(What I HAVE, what I KNOW) | The individual own an identity credential or a digital device storing personal cryptographic secrets. |
Behavior based identity verification | The individual is authenticated seamlessly based on its context and behavior following an evaluation of the risk he/she not be himself/herself. | To be used for very frequent access control (i.e. control of office workers) when security and convenience are both importants. Requires solid on-boarding before. | MEDIUM
(What I DO, Where I AM) | Having been screened and tracked on normal habits, locations, behaviors to be used for evaluation of fraud risk being online. |
Token based identity verification (SSO) | The individual has already been authenticated to a third party system allowing him to avoid a new identity verification and reuse the token. This mechanism is also named Single Sign On (SSO).
| To be used for online identity verification is usage of a digital identity. | Depends on previous identity verification
| Having been previously authenticated by a third party system and obtained a verifiable authentication token. |
Verifiable Credential | The individual has shared a verifiable credential to a third party system which allows its identity verification. | Can be used in various contexts online/offline. Can be related to one or several attributes of Identity. | High
(What you HAVE, what you ARE, what you WERE) | Require an electronic or physical support to verify the credential. If a verifiable credential can be verified offline, connectivity is required to verify the security chain. |
Through this list of capabilities we can see there are numerous but limited options for Identity Verification that can be combined or not, this list allows us to normalize them all into the following inputs for an identity verification:
Identifier: identifier referring to a digitally retrievable identity that can give access to an individual's attributes for verification. It is noted that several kinds of identifiers could be used to refer to the same person, which is particularly important to preserve privacy (see glossary).
Set of attributes: attributes provided by the individual or retrieved on/within its Identity credential for purpose of a matching versus a reference (online or ID credential), those attributes can be biographic data, biometrics data, or scan of identity evidence.
Authentication token: A previous identity verification token can be used for identity verification, this token would allow the current service provider to verify against the authenticating system the genuineness of the token.
6.2 Identity Management
Identity Building Block must offer an API to Enroll persons following a GovStack recommended Open Standard API. (REQUIRED)
Identity Building Block must offer capacity to perform an enrollment in one step. (REQUIRED)
Identity Building Block must offer capacity to perform an enrollment in multiple steps (i.e. demographic data collection, biometric data collections, supporting documents collections, etc.). (REQUIRED)
Identity Building Block must offer capacity to search, retrieve and update and enrollment made (if it has not been committed yet). (REQUIRED)
Identity Building Block must allow to control integrity and origin of an enrollment request by implementing enrollment meta-data about the context and actors of the enrollment, such as signature of data to ensure integrity. To ensure the integrity of the enrollment process, the Building Block must be able to implement technical controls so that only approved enrollment services can engage with the enrollment service. Cryptographic trust should be implemented.(REQUIRED)
Identity Building Block must support receiving encrypted data to ensure privacy protection and prevent data theft. (REQUIRED)
Identity Building Block must offer capacity to perform an enrollment offline which means not expecting interactions between registration client and server during the enrollment process, and data being uploaded as a whole packet. (REQUIRED)
Identity Building Block must support porting existing demographic, biometric, and other enrollment data from external servers during enrollment process. (REQUIRED)
Identity Building Block must keep track of the enrollment request identifiers within its internal management in order to facilitate traceability and troubleshooting. (REQUIRED)
Identity Building Block must generate a Unique Identifier for Identity created. This number must be kept secret within the Identity Building Block. (REQUIRED)
Identity Building Block must be capable to generate Virtual Identifier for referring to a User. The Virtual Identifier will be linked to the User's Unique Identifier. (REQUIRED)
Identity Building Block must offer an API to revoke a Virtual Identifier. In that case, the Alias won't be usable anymore for any Identity Building Block services. (REQUIRED)
Identity Building Block must be capable to attach an Alias Identifier to Unique Identifier for referring to a User. The alias will be an existing form of trusted identification of the User in another system. It could be for example an existing identity document number, an email address, a phone, etc. (REQUIRED)
Identity Building Block must offer an API to revoke the link to an Alias. In that case, the Alias won't be usable anymore for any Identity Building Block services. (REQUIRED)
Identity Building Block must offer APIs to update attributes of identities and to attach legal evidence of that identity change approval (often delivered by justice). (REQUIRED)
6.3 Credential Management
Identity Building Block must offer an API to request issuance, get status and manage Identity Credentials, following a GovStack recommended Open Standard API. (REQUIRED)
Identity Building Block must offer an API to manage the full life cycle of credentials related to an identity in an issuing system. The related credential must keep a strong and verifiable link with the individual identity and with the issuer. (REQUIRED)
Identity Building Block API must manage Digital Credentials. (REQUIRED)
Identity Building Block API must manage Physical Credentials. (REQUIRED)
Identity Building Block must offer an API allowing to request an identity credential issuance to a third-party credential management system. The information sent will have to be verifiable towards their issuer for auditability purposes, so they will have to be packed into Verifiable Credential format.
Identity Building Block must offer APIs to either push data for credential issuance in an issuance request or to be requested by the issuing system. (REQUIRED)
Identity Building Block must offer an API allowing to issue a similar credential to the one already issued before based on the credential ID number. (REQUIRED)
Identity Building Block must offer an API allowing to revoke an issued ID credential. This will be used, for example, when a document is damaged, stolen or definitely lost. (REQUIRED)
Identity Building Block must offer an API allowing to temporarily suspend and then un-suspend an issued ID credential. This will be used to disable an ID credential which has been lost, its holder suspending the time to search for it. After retrieval, the document should be unsuspended and usable again. If not retrieved after some time, the document should be revoked. (REQUIRED)
Identity Building Block must offer an API allowing to check the suspension status of a document. (REQUIRED)
Identity Building Block must offer an API to request the status of ID credentials. Status being related to their production, their delivery or their activation status. (REQUIRED)
Identity Building Block must offer an API to search for ID credentials using some of its attributes. The output must be restricted to being a document number which can facilitate an access request only. No information can be shared directly. (REQUIRED)
Identity Building Block must offer an API to retrieve a new copy of an ID credential already issued in case the current document has expired. The copy may be received electronically if is digital or delivered physically in case of a physical ID document. (REQUIRED)
Identity Building Block must offer an API to download a newly generated digital ID credential. (REQUIRED)
Identity Building Block must offer an API to share with a 3rd party a Digital ID Credential. (REQUIRED)
6.4 Subscription Management
Identity Building Block must offer an API for Subscribers to register for identity change events.(REQUIRED)
Identity Building Block must offer an API for Subscribers to register to Creation, Update and Disabling (person dead or considered as disappeared) events. (REQUIRED)
Identity Building Block must offer an API for Subscribers to collect event details after being notified of them. (REQUIRED)
6.5 Administration Management
Identity Building Block must prevent any unauthorized system or user to get access to data. (REQUIRED)
Identity Building Block must offer identity verification services only to a registered system or users. (REQUIRED)
Identity Building Block must offer the capacity to grant access to specific verification services for specific or all individuals that are data subjects and hence owners of that data. (REQUIRED)
Identity Building Block must respect principles of data security by design in order to maximize protection against hackers: data encryption, data isolation, data separation, data anonymization, data minimization. (REQUIRED)
Identity Building Block must implement security best practices in order to ensure the Identities it manages can be trusted. (REQUIRED)
Identity Building Block must implement a history of change for any identity must be retrievable and auditable by authorized users to investigate suspicious cases. (REQUIRED)
Identity Building Block must offer identity verification services only with preliminary informed consent on personal data usage of the concerned individual. (REQUIRED)
Identity Building Block must not disclose any personal unnecessary information as part of its services API, and when possible prefer Yes/No answer rather than sharing attributes. All Sensitive Personal Information/Personally Identifiable Information must not be written to logs/reporting databases. (REQUIRED)
Last updated