How to implement-Technical overview

Technical overview

For a more top level overview please visit https://www.idmee.no/idmee/

The solution consists of two parts.

  • A high level SDK which is easily integrated into an existing application or suitable for development of a new application.
  • A service where proof of process is issued by us to you. This consists of the transfer of a file archive at the end of the process which contains.
    • A signed PDF containing the relevant information extracted from the document as well as.
      • The picture of the user extracted (high resolution image).
      • A image captured during the face recognition and live-ness assessment.
      • A image captured of the passport front page.
    • A JSON file containing the information captured from the passport. This is suitable for processing when establishing the customer in other systems like CRM systems.
    • A detached PKCS7 file which is a signature of the archive transferred ensuring that the information has not been tampered with.

Please understand that this is not optical capture of the document. The information is read electronically from the chip embedded in the document. This information has been signed by an appropriate authority for the given nationality and we validate that a proper, valid and not recalled certificate has been used to do this.

Literally this is of better quality than what governments employ for border crossing and fare superior what is deployed in the current branch solutions.

SDK

Accessing the SDK

All the required software is hosted in an internet accessible maven repository. To access this repo you will need an access token which we will provide to you, should you choose to host these components in your own proxy repository due to rules and regulation this can be done subject to an agreement with us.

Starting the SDK

The SDK is made to be high level and easy to integrate.  Literally the following lines of code is what is required to execute the SDK.

config.setPublicKey("<VALUE PROVIDED BY US"); //This pair identifies you as a customer
config.setPrivateKey("<VALUE PROVIDED BY US>"); 
config.setEnvironment(Configuration.Environment.Testing); //FOR TEST ENVIROMENT 
config.setExpertModeEnabled(True/False); //Verbose help during the process or not default TRUE
config.setIdCardEnabled(True/False); //Optional, if National Schengen travel instrument is supported 
config.setPassportEnabled(True/False); //Optional, default value is TRUE 
DigitalIdentification.identify(me, config,123); //Start the SDK using the config and 123 as callback id

SDK Flow

Once the SDK is started it will handle the user dialogue and perform the following flow by itself, no code or any other functionality is required by the app  implementing the service.

flow_en

SDK Done

When the flow is completed successfully or unsuccessfully the parent app will be informed about the result and handle errors or retrieve the extracted information for further processing. This will again simply require very few lines of simple code and is optional in the sense that if only needs to be done if app needs this information in the app. The same information and more is transferred using the back channel to the customers defined reception point but that will not necessary have happened immediately since that is done using file transfer. The normal logic would be to proceed with whatever happens after a successful identification in the app and where the file transfer would serve as artifacts for legal archive and for update any back-end system that does not to be consistent immediately but where eventually consistent is required (like your CRM system).

protected void onActivityResult(int requestCode, int resultCode, Intent data) {
 Log.d("rkh", "Got requestCode " + requestCode + " and resultCode=" + resultCode);
 if (requestCode == 123 &&resultCode == Activity.RESULT_OK) {
 // access images and data, remember you used 123 when starting...
 Bitmap documentFaceImage = identityDocument.getDocumentFaceImage();
 Bitmap faceRecognitionImage = identityDocument.getFaceRecognitionImage();
 final String lastName = identityDocument.getLastName();
 final String firstName = identityDocument.getFirstName();
 final String soc = identityDocument.getSocialSecurityNumber();
 final String doc = identityDocument.getDateOfBirth();
 final String sex = identityDocument.getGender();
 final String nationality = identityDocument.getNationality();
 final String issuerCountry = identityDocument.getIssuingCountry();
 final String issueDate = identityDocument.getDateOfIssuance();
 final String expireDate = identityDocument.getDateOfExpiry();
 final String docType = identityDocument.getDocumentCode();
 final String docNumer = identityDocument.getDocumentNumber();
 final String when = identityDocument.getCreationTime();
 final String activeAuth = identityDocument.getActiveAuthenticationResult();
 final String rules[] = identityDocument.getRulesApplied();

Transfer Service

The transfer service can be done using several methods the recommended method is scp with public key authentication.

Information provided

The solution will provide a zip file which will contain 3 files.

  • A signed PDF document for archiving as part of the KYC process.
  • A JSON file containing the same information as the PDF but being machine readable and providing easy integration towards customer registers, CRM systems etc.
  • A PKCS7 detached signature for the JSON file proving tamper resistance.

PDF File

Please notice that for illustration the personal information has been obfuscated. As a regulated entity you will receive full personal information, if you happen to be a non finical institution you can receive some attributes non obfuscated (like name and date of birth) while others will remain partially obfuscated. This makes it possible for you to retrieve core information and still handle disputes where a strong case can be made by mapping.

  • Partially obfuscated to non obfuscated fields which will be known in a dispute.
  • Together with none obfuscated attributes like name, expiry date of document and issuing county.

This should make an compelling case on actual identification (even disregarding any trust of us as trust service attesting the documents) without holding a sensitive personal data set which will imply legal restrictions and a significant liability on your hand.

The solution provides a signed PDF file containing customer information and pertinent pictures.

A sample of the PDF content is provided. This contains the following information.

  • Information read in a secure manner from the passport. This information is read electronically (NFC) and the information was signed by the authority issuing the passport. The solution will check both the signatures and ensure that the certificate used to sign does indeed come from the authority in question.
  • An image electronically read from the passport. Again this is signed information and subject to the same validations as the other information read.
  • An image captured during the face recognition to serve as illustratively proof of this process.
  • An image captured of the front page of the passport. This can be used if visual inspection is required.

JSON file

As indicated this file contains the same information as the PDF (images excluded) but is suited for usage of other services enabling a fully automated process.

Please notice that for illustration the personal information has been obfuscated. As a regulated entity you will receive full personal information, if you happen to be a non finical institution you can receive some attributes non obfuscated (like name and date of birth) while others will remain partially obfuscated. This makes it possible for you to retrieve core information and still handle disputes where a strong case can be made by mapping.

  • Partially obfuscated to non obfuscated fields which will be known in a dispute.
  • Together with none obfuscated attributes like name, expiry date of document and issuing county.

This should make an compelling case on actual identification (even disregarding any trust of us as trust service attesting the documents) without holding a sensitive personal data set which will imply legal restrictions and a significant liability on your hand.

A sample JSON is given.

{

  "external": {

    "session_id": "dd7f0452-9c47-4084-88ac-704577074218",
    "session_created_time": "2018-01-31T08:19:06.379Z",
    "emrtd_session_id": "356fd7ee-d364-424a-8698-a7bfd81066af",
    "emrtd_document_expiry": "2028-01-15T00:00:00Z",
    "emrtd_document_dob": "6___23",
    "emrtd_document_issuing_country": "NOR",
    "emrtd_document_first_name": "R____",
    "emrtd_document_last_name": "KHAN",
    "emrtd_document_gender": "MALE",
    "emrtd_document_type": "PV",
    "emrtd_document_number": "____8703",
    "emrtd_document_nationality": "NOR",
    "emrtd_document_social_security_number": "0196________22",
    "emrtd_document_active_authentication_result": "passed",
    "rules_applied": [
      "acceptableDocumentCode",
      "issuerAcceptEUPlus",
      "passiveVerification"
    ]
  }

 

PKCS7 File

This file is present to protect the JSON file from tampering by proving a digital signature of the content.

This is a standard RSA based signature; there is a multitude of options to validate this signature towards a known document and trusted certificate

Customization

The solution permits several customable options.  The most common options are.

  • Definition of the different colors used.
  • Definition of logo used on the top of each page and the splash logo (Success logo).

Long term proof and reliable time-stamping

As an long term proof of process documents may be entered into the block chain. Since this will make attacks and forgery become more and more difficult as time goes by as  opposed to traditional signatures which will get easier and easier to crack and forge over time as computer resources get ore powerful and accessible this offers a long term proof that not only is the document untempered with but will also offer objective proof on when the process was objectively performed (time-stamping).

A further upshot of this is that this is not dependent on trust to anybody that being our company, the certificate CA issuing the signer certs or anybody else.

The general consensus that the current algorithms used in building the Merkel tree of the block-chain are safe even if quantum computing would be introduced and become generally available in the future.

SDK Footprint

This is not an easy question to answer since it depends on how many new downstream dependencies which are pulled in. In theory you may be using all of them already in which case the foot print will be extremely small and in the opposite case it will become larger.
Some metrics can however be given.

SDK Build size: + ~4.4 MB (Impact on APK)
SDK Install size: + ~8.65 MB (As installed on a users Phone)

Of cause again if you already have some of the downstream dependencies the impact on total size will be reduced.

Further information

Please use the form on the page and we will get back to you.