By sending several distinct elements (evidences) regarding someone’s identity, ID&V verifies and consolidates evidences to establish the identity of the user and a leel of trust (also known as Level of Assurance or LOA).

Read the Identity Document Capture & Verification product overview and the API Feedback reference to learn more about LOA and the various authentication scenarios.

The client application initiates a transaction with ID&V by creating a new identity. It submits evidences related to the user’s identity and finishes by requesting a "proof" of identity.

All these actions are performed by using REST web services detailed in the API Docs section. Follow the Getting Started section to implement a use case and to begin understanding the web service sequence (as well as the tools to perform simple ID proofing scenarios).

In an ID proofing scenario, there are three parties involved:

• The end user and the application they are interacting with (User Agent or UA)
• The Relying Service (RS) the user wants to access which relies upon ID&V for the identity proofing process
• The ID proofing service (ID&V) that helps the user prove their identity to the relying service

For security reasons, the authorized requests and result details that are communicated to the RS or the UA have some slight differences, restricting the UA information to what it “needs to know”.

The UA API keys must be used by the client application (UA) that is in the user’s hands.

The RS API keys must be only used by the Relying Service backend.

For example, detailed scoring or antifraud results are communicated only to the client application using the RS API key.

Available web services are documented in API Docs section and can be experimented with by following the Postman integration Guide in the Portal.

An apikey is a unique value generated to differentiate client applications that grants access to ID&V APIs. It must be sent in the headers of all web services calls.

It is provided by the dashboard administrator and can be changed in the Account section of the ID proofing dashboard, if you have the proper access rights.

Apikeys carry the type of client application: USER AGENT (UA) or RELYING SERVICE (RS).

Consent is a notification from the client application to ID&V that the end-user consents to their personal information (evidences) being processed by ID&V.

Depending on the service configuration, some evidence processing requires a preliminary consent.

By default, consent is required for the following evidence verifications:

• PORTRAIT for biometric face recognition
• GIV for a verification of the user evidence against a government identity verification source

To use any of these services, the client application must provide the appropriate consent via the consent API. All consents can be sent in one request.

• Standard maximum accepted size for these images is 2 MB
• Minimum recommended resolution is 300 dpi
• Supported formats are jpeg and png
• Document images should be in color and of good readable quality
• All corners of document must be visible
• No glare, blur, shadows or other artifacts should prevent readability of the document

• Standard maximum accepted size for these images is 2 MB
• Supported formats are jpeg and png
• The face should be front facing and clear of all obfuscation artifacts so that every part of the face is visible

Document front and back images are processed through the same API in the same request. Whenever a DocumentFront is sent in a request, a DocumentBack can also be sent as a parameter.

It’s important not to do it in separate requests as the data regarding same evidence types will override previously sent information.

Submitting an evidence is an asynchronous process.

1. For the client application to retrieve the processing results, it must implement a polling process on the evidence status.
2. While an evidence is being processed, its status will be set to PROCESSING.
3. Keep polling until this status changes to VERIFIED, INVALID, or NOT_VERIFIED. We recommend doing a polling request once per second until any change is noticed.

Check the error related documentation in our API Feedback Reference section to match the error code to its corresponding interpretation.

Whereas ID&V does its best to support all use cases and documents, some capabilities have limitations or are yet to be implemented. They are continuously being improved with each new version of ID&V. Contact your Customer Support representative for further assistance.

Upgrade paths describe the possible additional evidence submissions that would increase the LOA, if their verification is successful.

When requesting proof, the transaction related to your identity ends. You cannot submit any additional evidence, but will need to start a new identity proofing process.

A new identity automatically expires 30min after it is created or when requesting the proof.

After this time limit, all identity evidences submitted are discarded. A new identity should be created if the first transaction wasn’t properly concluded by requesting the proof.