Skip to content

Latest commit

 

History

History
566 lines (404 loc) · 55.1 KB

FRS-Authentication-Services.md

File metadata and controls

566 lines (404 loc) · 55.1 KB
Raw

Table Of Contents

1. Single factor Authentication

1.1 Biometric Authentication [↑]

A. MOSIP system can evaluate the Individual's photo match with the corresponding photo in the Auth server

Upon receiving an authentication request, the system evaluates the Individual's photo match with the corresponding photo in the Auth server as per the following steps:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric data is sent in Base-64 encoded format
  3. System validates if the time period between the current time stamp and the request time stamp is <= time period. Refer to the features related to time stamp validation.
  4. System validates that total number of face record(s) should not exceed 1
  5. The face record in the input parameter against the mapped UIN/VID of the individual in the auth database is matched. Refer to the features related to Map VID to UIN.
  6. The system then generates a match score based on the level of the match of the face
  7. 1:1 mapping is performed by the SDK and match score is provided. The system then proceeds to execute compare against the face threshold.
    • NOTE: Biometric Authentication match score generation is stubbed. The actual integration with SDK will be covered in forthcoming implementation.
  8. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  9. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

B. Authenticate the face of the Individual by comparing the match score of the photo against the threshold

Upon receiving an authentication service request, the system authenticates the face of the Individual by comparing the match score of the photo against the threshold as per the following steps:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric data is sent in Base-64 encoded format.
  3. Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  4. The system retrieves the threshold level configured which is acceptable for a match and then validates if the match score is equal to greater than the threshold level and sets the status as 'Y' for authentication
  5. Constructs the authentication response based on validation results
  6. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  7. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  8. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

C. Evaluate the Individual's fingerprints with the corresponding fingerprint in the Auth server [↑]

Upon receiving an authentication request, the system evaluates the Individual's fingerprints with the corresponding fingerprint in the Auth server as per the following steps:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric is sent in Base-64 encoded format.
  3. The system then validated the following:
    • Validates if the time period between the current time stamp and the request time stamp is <= time period (n is an admin configuration). Refer to the features related to time stamp validation.
    • Validates if duplicate fingers are used in input
    • Validates if total number of finger print records exceed 2
  4. The system then matches finger print records in the input parameter against the mapped UIN/VID of the individual in the auth database. Refer to the features related to Map VID to UIN.
  5. The system then generates a match score based on the level of the match of the fingerprints and proceeds to execute compare against fingerprint threshold
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  7. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

D. Authenticate the fingerprints of the Individual by comparing the match score of the fingerprint against the threshold (BioAuthService)

Upon receiving an authentication request, the system authenticates the fingerprints of the Individual by comparing the match score of the fingerprint against the threshold. The system can integrate with Fingerprint scanner and generate match score as per the following steps:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric is sent in Base-64 encoded format.
  3. Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  4. The system retrieves the threshold level configured which is acceptable for a match
  5. The system then validates if the match score is equal to greater than the threshold level and sends a response
  6. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  7. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  8. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

E. Support two-finger authentication so that the quality of incoming fingerprints is better [↑]

Upon receiving an authentication request, the system supports two-finger authentication so that the quality of incoming fingerprints gets better as per the below process:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric is sent in Base-64 encoded format
  3. The system validated the following:
    • Validates if the time period between the current time stamp and the request time stamp is <= time period (n is an admin configuration). Refer to the features related to time stamp validation.
    • Validates if duplicate fingers are used in input, if duplicate encoded value is used in the input for fingers - updated logic
    • Validates if single finger print record contains more than one finger
    • Validates if total number of finger print records exceed 2
  4. The system then matches first finger print record in the input parameter against the mapped UIN/VID of the individual in the auth database. Refer to the features related to Map VID to UIN.
  5. The system will integrate with BioAPI compositeMatch function logic which returns composite match score.
    • NOTE: The logic of average or sum, etc. will be part of BioAPI implementation. The current stubbed implementation of BioAPI performs an average.
  6. The system retrieves the composite finger threshold configured which is acceptable for a match
  7. The system validates if the composite match score is equal to greater than the composite finger threshold
  8. Constructs the authentication response based on validation results
  9. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  10. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  11. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

F. Evaluate the Individual's IRIS match with the corresponding IRIS in the Auth server [↑]

Upon receiving an authentication request, the system evaluates the Individual's IRIS match with the corresponding IRIS in the Auth server as per the following steps:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The biometric is sent in Base-64 encoded format
  3. The system validated the following:
    • Validates if the time period between the current time stamp and the request time stamp is <= time period (n is an admin configuration). Refer to the features related to time stamp validation.
    • Validates if duplicate irises are used in input
    • Validates if total number of Iris records exceeds 2
    • Validates if single iris record is present in the input
    • The system matches iris record in the input parameter against the mapped UIN/VID of the individual in the auth database. Refer to the features related to Map VID to UIN.
  4. The system then generates a match score based on the level of the match of the Irises. The SDK will provide the match score.
    • NOTE: Biometric Authentication match score generation is stubbed. The actual integration with SDK will be covered in forthcoming implementation.
  5. The system validates if two iris records are present in the input
  6. The system matches each of the iris records in the input parameter against the corresponding records of the mapped UIN/VID of the individual in the auth database and then generates a match score based on the level of the match of the Irises. Refer to the features related to Map VID to UIN.
  7. Match score 1 and Match score 2 are generated for each images. The SDK provides the match score
    • NOTE: Biometric Authentication match score generation is stubbed. The actual integration with SDK will be covered in forthcoming implementation.
  8. The system generates a composite match score by summing up the match scores for the first and the second iris Images
  9. The system proceeds to execute compare against Iris threshold
  10. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  11. Alerts and warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages.

Please refer to the Biometric Authentication API for more details.

G. Authenticate the IRIS of the Individual by comparing the match score of the IRIS against the threshold [↑]

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The system retrieves generated score match
  3. The biometric is sent in Base-64 encoded format.
  4. Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  5. The system then validated the following:
    • Validates if single iris records are present in the input
    • Retrieves the threshold level configured which is acceptable for a match
    • Validates if the match score is equal to greater than the threshold level
    • Validates if two iris records are present in the input
    • Retrieves the composite threshold level configured which is acceptable for a match
    • Validates if the composite match score is equal to greater than the composite threshold
  6. Constructs the authentication response based on validation results
  7. The system proceeds to execute compare against Iris threshold
  8. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  9. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail.
  10. Alerts and Warning messages for data type violation are sent as per data definition. Please refer Git for more details on the type of error messages

Please refer to the Biometric Authentication API for more details.

Link to design

1.2 Demographic Authentication [↑]

A. Strategy for Authentication

MOSIP supports only exact match for the demographic authentication of the individual and does not perform any validations related to partial match and phonetics match. No error messages related to partial match and phonetics match are triggered.

B. Demographic (Address) Authentication

No weightage is provided to any field\s but exact match strategy is adopted for demographic address

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system validates if each of the address line items in the input parameter is same as the address line items against the mapped UIN/VID of the individual in the auth database in the respective language for each address element. Refer to the features related to Map VID to UIN.
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the Demographic Authentication API for more details.

NOTE:

  1. The address attributes are generalized as location 1, location 2 and location 3
  2. The SI has to define and map the address specific attributes against addressLine2, addressLine3, and location specific attributes against location1, location2, location3 of a country. For example: addrLine1 means House No, addrLine2 means Street No, and addrLine3 means Locality; similarly loc1 means Local Administrative Authority, loc2 means Province and loc3 means Region.

Please refer Git for the address based Normalization Rules

C. Verify the Age of the individual so that the individual is authenticated

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system retrieves the DOB of the individual in the auth database based on the mapped UIN/VID. Refer to the features related to Map VID to UIN.
  4. The system calculates the age of the individual based on the DOB.
  5. Validates if the Age of the individual is greater than or equal to the Age in the input parameter
  6. Constructs the authentication response based on validation results
  7. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  8. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the Demographic Authentication API for more details.

D. Match Name of the individual in the database so that the individual is authenticated

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system compares the name in the input parameter with the Name saved in the respective language in the auth database
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages

Please refer to the Demographic Authentication API for more details.

E. Match phone number of the individual in the database so that the individual is authenticated [↑]

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system matches the phone number in the input parameter with the phone number of the individual in the auth database based on the mapped UIN/VID. Refer to the features related to Map VID to UIN.
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages

Please refer to the Demographic Authentication API for more details.

F. Match e-mail ID of the individual in the database so that the individual is authenticated [↑]

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system matches the e-mail id in the input parameter with the phone number of the individual in the auth database based on the mapped UIN/VID. Refer to the features related to Map VID to UIN.
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the Demographic Authentication API for more details.

G. Match gender of the individual in the database so that the individual is authenticated [↑]

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system matches the Gender in the input parameter with the Gender of the individual in the auth database based on the mapped UIN/VID. Refer to the features related to Map VID to UIN.
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the Demographic Authentication API for more details.

H. Match DOB of the individual in the database so that the individual is authenticated

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  3. The system matches the DOB in the input parameter with the DOB of the individual in the auth database based on the mapped UIN/VID. Refer to the features related to Map VID to UIN.
  4. Constructs the authentication response based on validation results
  5. Integrates the response with the static token generated for the authentication request. Refer to features related to generate a Static Token.
  6. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the Demographic Authentication API for more details.

Link to design

1.3 OTP Authentication [↑]

A. Trigger OTP to an individual so that the individual can be authenticated based on OTP

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request the system validates if the Timestamp of OTP generation request is older than 20 min. Refer to the features related to time stamp validation.
  3. The system generates the OTP for the request
  4. Retrieves the mode of communication (i.e) e-mail or phone number configured for sending the OTP
  5. The system validates if the configured mode of communication is also registered and triggers and OTP
  6. Constructs the authentication response based on validation results with masked mobile and masked e-mail
  7. The system proceeds to validate OTP as per the defined standards
  8. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the OTP Authentication API for more details.

B. Trigger SMS to the Individual's mobile for OTP Trigger request [↑]

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The system retrieves the mode of communication (i.e) e-mail or phone number configured for sending the notification
  3. Validates if the configured mode of communication is also registered
  4. The system fetches the notification template as per admin configuration
  5. Triggers notification as per the defined and configured template and in the default language English. Please refer Git for more details on the type of error messages.

Please refer to the OTP Authentication API for more details.

C. Respond with masked e-mail and masked phone number for OTP trigger request

The system follows the following steps to include masked e-mail and phone in the OTP request response

  1. Retrieves the mode to which OTP will be sent as per the below logic
    • If the configured mode of communication is also registered sends OTP to the configured and registered mode
    • If the configured mode = e-mail and Registered Mode is Mobile; then sends OTP to Mobile
    • If the configured mode = phone and Registered Mode is e-mail; then sends OTP to e-mail
    • If registered mode is none, then send error code.

Please refer Git for more details on the type of error messages.

  1. If the communication mode = mobile
  2. Mask the mobile no of the individual as per logic below and include the masked mobile in the OTP request response
  3. If the communication mode = e-mail
  4. Mask the e-mail of the individual as per the logic below and include the masked e-mail in the OTP request response
  5. If the communication mode = mobile and e-mail
  6. Mask both the mobile no and the email as per the logic below and include the both in the OTP request response

Logic for masking mobile [↑]

  1. No of digits in the mobile number to be retrieved – say n

  2. Mask first {(50% of the n digits) + 1} digits of the mobile number

    • Note: 50% in case of decimal means rounded to the greatest whole number

Eg:

Original phone number: 8347899201

Masked phone number: XXXXXX9201

Logic for masking e-mail

  1. Consider the characters prior to the symbol ‘@’
  2. Assign a position to each character
  3. Mask every alternate 2 characters starting from position 1

Eg:

Original e-mail: [email protected]

Masked e-mail: [email protected]

D. Trigger e-mail to the Individual's mail-ID for OTP Trigger request

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The system then retrieves the mode of communication (i.e) e-mail or phone number configured for sending the notification
  3. Validates if the configured mode of communication is also registered
  4. Fetches the notification template as per admin configuration
  5. Triggers notification as per the defined and configured template and in the default language English
  6. Please refer Git for more details on the type of error messages.

Please refer to the OTP Authentication API for more details.

E. Validate OTP provided by an Individual so that the individual can be authenticated based on OTP

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Upon receiving an authentication request with required parameters a the system validates if the transaction id matches with transaction id value of OTP Generation Request
  3. Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config). Refer to the features related to time stamp validation.
  4. Validates if the OTP in the input parameter is same as the OTP triggered for the individual to the registered phone number and/or e-mail
  5. The system checks the validity of the OTP
  6. Constructs the authentication response based on validation results
  7. The system proceeds to send Notification SMS and Notification E-mail. Refer to features related to Trigger SMS and Trigger E-mail. Please refer Git for more details on the type of error messages.

Please refer to the OTP Authentication API for more details.

1.4 Common Features for all Authentication Types [↑]

A. Validate the timestamp of the authentication request

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. The system then validates the following:
    • Validates if the time period between the current time stamp and the request time stamp is <= 20 min
    • Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config)---> Default value-24 hrs
    • The system validates the mode of authentication as per the defined standards
    • Then triggers error messages as configured.
  3. MOSIP supports standard time for timestamps of authentication requests and responses
    • The timestamp of the Authentication, e-KYC, OTP trigger requests and responses will support IS0-8601 standard.
    • The partners in a country are expected to send the timestamp in the request in UTC with time zone
    • MOSIP returns the timestamp in the response in UTC with Time zone

B. Locate the UIN of the individual in the Auth database so that the individual can be authenticated

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

  1. The system matches the input UIN from the individual with the UIN in the auth database (Complete match) and sends an error message in case of any mismatch
  2. Please refer Git for more details on the type of error messages.

C. Map VID to UIN of the individual in the Auth database so that the individual can be authenticated [↑]

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

  1. The system then validates if the VID is mapped to an UIN in the database and retrieve the UIN
  2. The system proceeds to Match UIN as per defined standards
  3. Please refer Git for more details on the type of error messages.

D. Generate a static token ID for each MOSIP authentication request, to facilitate authentication [↑]

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

The system then performs the following steps to generate a static token ID

The system retrieves the UIN and Partnerid for token Id generation

  1. Generates tokenID based on the defined standards

  2. The tokenID is unique for a UIN and partnerId combination. The same id should be returned if any auth request is received from the same UIN and partnerId combination

  3. The tokenID is generated for every authentication request

  4. The length of tokenID is configurable by the ADMIN (the default length of 36 digits)

  5. The UIN and partnerid are not be derivable from the tokenId

  6. The tokenID is a random number generated

  7. The tokenId does not contain any alphanumeric characters and should contain only numeric characters

  8. The number does not contain the restricted numbers defined by the ADMIN

  9. The generated tokenid is integrated to the authentication response along with other parameters.

    • Note: The Authentication is integrated for both successful and failure authentications (i.e) in all cases where authentication notifications are triggered.

  10. The system then captures and stores the transaction details for audit purpose.

E. Trigger SMS to the Individual's mobile for every authentication request

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

The system then performs the following steps to Trigger SMS to the Individual's mobile for every authentication request

  1. Retrieves the mode of communication (i.e) mobile configured for sending the notification
  2. Validates if the configured mode of communication is also registered
  3. Fetches the notification template as per admin configuration and triggers notification as per the defined and configured template and in the default language English
  4. Please refer Git for more details on the type of error messages.

F. Trigger e-mail to the Individual's e-mail ID for every authentication request [↑]

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

  1. The system retrieves the mode of communication (i.e) e-mail configured for sending the notification
  2. The system validates if the configured mode of communication is also registered
  3. Fetches the notification template as per admin configuration and triggers notification as per the defined and configured template and in the default language English
  4. Please refer Git for more details on the type of error messages.

Link to design

Link to design

2. Multi-factor Authentication [↑]

We can perform various combinations of authentication using various modalities as listed for Single Factor Authentication.

3. Offline Authentication

3.1 QR Code based Authentication (WIP) [↑]

4. KYC Service

4.1 Profile Sharing based on Policy [↑]

KYC Service is offered based on the individual’s consent using OTP or Biometric (Fingerprint/IRIS/Face) Authentication in the authentication request.

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

The system then validates the following:

  1. Validates digital signature in the certificate
  2. Validates the certificate
  3. Validates if the partnerID belongs to a registered partner
  4. Validates if the partner status is active
  5. Retrieves the policy constituting for the partnerID and partner api key
    • NOTE: (For points 3, 4 and 5) Partners Authentication and Authorisation is only a proxy implementation due to pending integration with Partner Management services.
  6. Validates if the auth type specified in the request is one of the policies retrieved.
  7. Validates if the auth type specified in the request is one of the permissible auth types for e-KYC for the country as per the set configuration
  8. Validates if the retrieved policy contains one e-KYC policy (the policy containing demographic attributes to be returned)
  9. The system performs all the validation of the "auth" as per standards and encodes the auth response
  10. Validate the status of the auth response and proceed only if the status is successful
  11. The system proceeds to construct the e-KYC response element, which will be encoded and encrypted.
  12. The system integrates the response with the static token generated for the authentication request
  13. Constructs the authentication response based on validation results
  14. Validate e-KYC permissions for e-KYC partner as per the e-KYC policies retrieved and identify the demo fields configured to be part of the response
  15. Appends the response with the demographic and id fields as per the policy
  16. The system validates the sec_language attribute in the request and appends the response with the demographic fields in language requested.
  17. The system proceeds to send Notification SMS
  18. Alerts and Warning messages for data type violation are sent as per data definition

Please refer to the eKYC API for more details.

Link to design

5. Partners Authentication and Authorisation

  • NOTE: Partners Authentication and Authorisation is only a proxy implementation due to pending integration with Partner Management services

5.1 MISP License Authentication [↑]

Authenticate and authorise the MOSIP Infrastructure Service Provider (MISP)

MOSIP can authenticate and authorise the MOSIP Infrastructure Service Provider (MISP) as per the following steps listed below:

  1. The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.
  2. Validates if the MISP-license key has not expired
  3. Validates if the MISP-license key belongs to a registered MISP (Note: All the MISPs will be registered through MOSIP admin portal and the MISP-license key should belong to one of the registered MISP entities)
  4. Validates if the MISP-license key status is active
  5. Proceeds to execute e-KYC/Auth partner authentication and authorisation as per defined standards
  6. Captures and stores the transaction details for audit purpose.
  7. Alerts and warning messages for data type violation are sent as per data definition.

Please refer to the Authentication Service API for more details.

5.2 Partner Policy Authentication [↑]

Authenticate and authorise Auth Partner- proxy implementation

The authentication service request should have a defined set of parameters. Please refer to data definition in Git for more details on required parameters.

The system then validates the following:

  1. Validates the digital signature in the certificate
  2. Validates the certificate
  3. Validates if the partnerID belongs to a registered partner
  4. The system also validates if the partner status is active
  5. Retrieves all the policies constituting the partnerID and partner api key
  6. Validates if the auth type specified in the request is one of the policies retrieved for the partner
  7. Validates if the time period between the current time stamp and the request time stamp is <= time period (n - admin config)
  8. Validates if the "authvalue" in the input parameter is same "authval" stored in the database for the mapped UIN and VID
  9. The system constructs the authentication response based on validation results and sets the authentication status as 'Y' only if the pinval matches.
  10. The system then integrates the response with the static token generated for the authentication request
  11. Constructs the authentication response based on validation results
  12. The system proceeds to send Notification SMS
  13. Alerts and Warning messages for data type violation are sent as per data definition

Please refer to the Authentication Service API for more details.

6. Lock/Unlock Authentication Types [↑]

6.1 Lock Authentication Types

When an individual wants to lock a particular authentication type using resident services, for example, locking demographic and/or biometric authentication, the system locks the requested authentication type after certain validations. After the requested authentication type is locked for the individual, then he/she will not be able to authenticate himself/herself by using locked authentication type.

6.2 Unlock Authentication Types

When an individual’s particular authentication type is locked and wants to unlock using resident services, for example, unlocking demographic and/or biometric authentication, the system unlocks the requested authentication type after certain validations. After the requested authentication type is unlocked for the individual, then he/she will be able to authenticate himself/herself by using unlocked authentication type.

7. Authentication Device Support

7.1 Registered Devices and Open Devices [↑]

The authentication services can be utilized only by a trusted partner and a registered set of devices. A device can be registered in the MOSIP ecosystem by the device provider through the device register API exposed by MOSIP. For details related to Device Registration and De-Registration features please refer this link.

List of Configurable Parameters and Processes [↑]

  1. Configurable Parameters

    Link to Configurable Parameters of Authentication Services

  2. Configurable Processes

  • (Work in Progress)

Authentication Services API [↑]

Refer to Wiki for more details on Authentication Services API

Process View [↑]

Link to Process View of Authentication Services