Deployment

Deployability via container

Interface

Fulfillment of Service API requirements

Insert number or “all”

Fulfillment of REQUIRED API related requirements in the Architecture BB specifications (ch. 5.1, 5.3, 5.4, 5.6, 5.13)

Insert number or “all”

Requirement Specification

Fulfillment of REQUIRED Key Digital Functionalities stated in the respective BB specifications

Insert number or “all”

Fulfillment of REQUIRED cross-cutting and functional requirements stated in the respective BB specifications

Insert number or “all”

Fulfillment of REQUIRED cross-cutting requirements stated in the Architecture BB specifications

Insert number or “all”

Must be deployable via container

 Yes, IDBB can be deployed via containers

 Identity Usage

 Identity Management

 Credential Management

 ID BB Specifications in progress

 Subscription Management

 Websub API’s will be used. These are HTTP API’s. ID BB Specifications in progress

Administration Management

 Enrollment Services

 Multi-Factor Authentication

 Numerical Digital ID Attribute

 Consent Management

ESignet consent is provided.

Trust Framework

 Identity Building Block must offer an API to verify Identities following a Gov Stack recommended Open Standard API.

Identity Building Block must offer an API to Verify Identity of an individual based on one of its known identifiers.

 Identity Building Block must offer an API to retrieve personal attributes of an individual from one of its identifiers.

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

MOSIP does not support this feature.

 Identity Building Block must offer Identity Verification services based on login/password

 Not Applicable

 Identity Building Block must offer Identity Verification services based on visual physical identity credential identity control

 Identity Building Block must offer Identity Verification services based on eID card identity data control

 API’s to provide the credential to eID partner is available, however eID printing is outside the scope of ID BB.

 Identity Building Block must offer Identity Verification services based on eID card based identity verification

 API’s to provide the credential to eID partner is available, however eID printing is outside the scope of ID BB.

 Identity Building Block must offer Identity Verification services based on Fingerprint 1:1 matching versus ID credential

 Identity Building Block must offer Identity Verification services based on Fingerprint 1:1 matching online

 Identity Building Block must offer Identity Verification services based on Fingerprint recognition

 Identity Building Block must offer Identity Verification services based on Facial 1:1 matching versus ID credential

 Identity Building Block must offer Identity Verification services based on Facial 1:1 matching online

 Identity Building Block must offer Identity Verification services based on Facial recognition

 Identity Building Block must offer Identity Verification services based on Iris 1:1 matching versus ID credential

 Identity Building Block must offer Identity Verification services based on Iris 1:1 matching online

 Identity Building Block must offer Identity Verification services based on Iris recognition

 Identity Building Block must offer Identity Verification services based on OTP

 Identity Building Block must offer Identity Verification services based on Online ID credential matching

 Identity Building Block must offer Identity Verification services based on Online PKI based identity verification

 Identity Building Block must offer Identity Verification services based on Behavior based identity verification

 Identity Building Block must offer Identity Verification services based on Token based identity verification (SSO)

 Identity Building Block must offer Identity Verification services based on Verifiable Credential

Identity Building Block must offer an API to Enroll persons .

Identity Building Block must offer capacity to perform an enrollment in one step.

Identity Building Block must offer capacity to perform an enrollment in multiple steps (i.e. pre-enrollment and enrollment).

Identity Building Block must offer capacity to search, retrieve and update and enrollment made (if it has not been committed yet).

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.

Identity Building Block must support receiving encrypted data to ensure privacy protection and prevent data theft.

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.

Identity Building Block must keep track of the enrollment request identifiers within its internal management in order to facilitate traceability and troubleshooting.

Identity Building Block must generate a Unique Identifier for Identity created. This number must be kept secret within the Identity Building Block.

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.

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.

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.

ID BB currently does not support attaching an alias.

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.

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

Identity Building Block must offer an API to request issuance, get status and manage Identity Credentials, following a GovStack recommended Open Standard API.

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.

Identity Building Block API must manage Digital Credentials.

Identity Building Block API must manage Physical Credentials.

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.

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.

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.

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.

Identity Building Block must offer an API allowing to check the suspension status of a document.

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.

To be handled by CIDM

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.

Credential Issuance to third party is available , credential search to be handled by CIDM

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.

Identity Building Block must offer an API to download a newly generated digital ID credential.

Identity Building Block must offer an API to share with a 3rd party a Digital ID Credential.

5.1 Follow TM Forum Specification REST API Design Guidelines Part 1 (REQUIRED)

5.2 Follow TM Forum Specification REST API Design Guidelines Parts 2-7 (RECOMMENDED)

5.3 Communicate with other BBs only via API (REQUIRED)

 For notification it is websub API’s which are HTTP API’s

5.4 APIs must be Versioned (REQUIRED)

5.5 Documentation must be Provided (REQUIRED)

5.6 Provide an OpenAPI specification (REQUIRED)

 Yml files checked into Govstack github

5.7 Building blocks must be deployable as a container (REQUIRED)

 Yes, IDBB uses containers.

5.8 Include all deployment scripts (RECOMMENDED)

 Yes, we have added all our deployment script in tf-govstack github repo.

5.9 Comply with GDPR Principles (REQUIRED)

5.10 Include Support for Capturing Logging information (REQUIRED)

5.11 Use Web Hooks for Callbacks (REQUIRED)

 Web hooks compliant adapter

5.12 Enforce Transport Security (REQUIRED)

5.13 GET and PUT APIs must be Idempotent (REQUIRED)

5.14 Use Stateless APIs wherever Possible to Enhance Scalability (RECOMMENDED)

5.15 Include Transaction/Trace/Correlation IDs (RECOMMENDED)

5.16 Include Clearly-Defined Key Rotation Policies (RECOMMENDED)

5.17 Databases should not Include Business Logic (RECOMMENDED)

5.18 Use only Unicode for Text (REQUIRED)

5.19 Use ISO8601/UTC for Timestamps (REQUIRED)

5.20 Building Blocks must be Autonomous (REQUIRED)

5.21 Use Secure Configuration (REQUIRED)

5.22 Design for Asynchronous First (RECOMMENDED)

5.23 Use Standardized Data Formats for Interchange (REQUIRED)

5.24 Use Existing Standards for Data Interchange, Where Available (RECOMMENDED)

5.25 Use I/O Sanitization (RECOMMENDED)

5.26 Provide a Compliance Test Mock/Example Implementation (OPTIONAL)

 In Progress

5.27 Building blocks should be Localizable (RECOMMENDED)

5.28 Use NTP Synchronization (RECOMMENDED)

Not Applicable