To use the IDCloud platform, it is necessary to authenticate via an access token, using the authentication system known as OAuth2.

The OAuth2 authentication system from Unico supports server-to-server interaction between a web application and Unico's services.

For this scenario, you will need a service account, which is an impersonal account belonging to your application and not to an individual user. Your application calls Unico’s APIs on behalf of the service account, so users are not directly involved. This scenario is called “two-legged OAuth,” or “2LO.” Typically, an application uses a service account when the application calls Unico’s APIs to work with its own data rather than user data.

To meet the various use cases of your operation, the capabilities of IDCloud have different availability depending on the integration methods. Below, check out the table with all the usage possibilities, separated by integration method:

Overview

Welcome to the Unico IDCloud platform REST API documentation! On this page, you'll find everything you need to know to enhance the security and quality of your applications using our REST API.

Learn more about

What is the Unico IDCloud platform?

IDCloud is the only identity verification platform that combines security with guaranteed accuracy. With it, you can validate user identities in a simple and intuitive way, using only a selfie, ensuring smoothness and protection in your verification processes.

To learn more about our capabilities, visit the following page:

Integration Overview

After creating and configuring a service account, your application needs to complete the following steps:

1. Create a JSON Web Token (JWT), which includes the header, payload, and signature.

2. Request an Access Token from the OAuth2 authentication platform.

3. Process the JSON response returned by the authentication platform.

If the response includes an access token, you can use it to make requests to Unico product APIs for which the service account has access permissions. (If the response does not include an access token, your JWT or token request may be incorrect, or the service account might lack the necessary permissions to access the requested resources.)

The access token generated in the above request has a default validity of 3600 seconds, but this may vary based on the security configuration set for your company. When the access token expires, your application must generate a new JWT, sign it, and request a new access token from the authentication platform.

1 - Creating the JWT

A JWT (JSON Web Token) consists of three parts: a header, a payload, and a signature. The header and payload are JSON objects, which are serialized in UTF-8 and then encoded using Base64url encoding. This encoding ensures resilience against modifications due to repeated encoding operations. The header, payload, and signature are concatenated using a period (.) separator.

A JWT is structured as follows:

{Header in Base64url}.{Payload in Base64url}.{Signature in Base64url}

The base text for the signature is formed in the following way:

{Header in Base64url}.{Payload em Base64url}

1.1 - Forming the JWT Header

The header consists of two fields that specify the signing algorithm and the token format. Both fields are mandatory, and each field has only one value. Service accounts rely on the RSA SHA-256 algorithm and the JWT token format.

As a result, the JSON representation of the header is as follows:

{"alg":"RS256","typ":"JWT"}

The Base64url representation is as follows:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

This ensures that both header and payload are properly encoded before signing, which is crucial for secure authentication.

1.2 - Forming the JWT Payload

The JWT payload contains information about the JWT, including the requested permissions (scopes), the account requesting access, the issuer, the time the token was issued, and the token's lifespan. Most fields are mandatory. Like the JWT header, the payload is a JSON object and is used in the composition of the signature.

1.3 - Required Fields

The required fields in the JWT are shown in the table below. They can appear in any order within the payload.

Understand how the conversion works for the issuance (iat) and expiration (exp) fields of the JWT, and also see examples of how to use the values of these fields here. Additionally, the "iat" field should reflect the current time in the required format, and the "exp" field must adhere to the calculation below:

exp = iat + 3600

The representation of the mandatory JSON fields in the JWT payload is as follows:

{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, //This is just an example. Use the current value generated here.
  "iat": 1626293376 //This is just an example. Use the current value generated here.
}

1.4 - Calculating the Signature

The JSON Web Signature (JWS) specification is the mechanism that guides the calculation of the signature for a JWT. The input content for the signature calculation is the byte array of the following content:

{Header in Base64url}.{Payload in Base64url}

The same algorithm specified in the header of the JWT must be used for the signature calculation. The only signature algorithm supported by the OAuth2 authentication platform is RSA using SHA-256. It is expressed as RS256 in the alg field of the JWT header.

Sign the UTF-8 representation of the input content using SHA256withRSA (also known as RSASSA-PKCS1-V1_5-SIGN with SHA-256 hash) with the private key that was created and associated with the service account (the .key.pem file generated from the request received by email). The output content will be a byte array.

The signature must then be encoded in Base64url. The header, payload, and signature must be concatenated with a period (.). The result is the JWT. It should be in the following format: {Header in Base64url}.{Payload in Base64url}.{Signature in Base64url} Below is an example of a JWT token before Base64url encoding:

{Header in Base64url}.{Payload in Base64url}.{Signature in Base64url}

Below is an example of a JWT token before Base64url encoding:

{"alg":"RS256","typ":"JWT"}.
{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, //This is just an example. Use the current value generated here.
  "iat": 1626293376 //This is just an example. Use the current value generated here.
}.
[byte array from signature]

Below is an example of the JWT that has been signed and is ready for transmission:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY291bnRf
bmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb
3BlIjoiKiIsImV4cCI6MTYyNjI5Njk3NiwiaWF0IjoxNjI2MjkzMzc2fQ.JsymP3NZdgCSqeNlgsOM2
-AQ7M450NxFnZnnaKSu4Q8g12QGEIvvM4EhCokUHfwk5s7pOpm2UD_Ng3Hb5g_wgrjfiVSLWH5Q2wYg1AvfLqo
YSoJWaMHm9KL0kpv32XdDD8TZVR-MVd2VBHmCMVbV6gvk8buUoK1HZDN7g84PaY3bfgcB3RKU-
H55lR8yyJjZxToIv17-wfla2G99uaMEFNGX0ZSE7ETn5Z8-WypmFrNAK0TM58upzvfVI6_-
gY4cj4iQvmRbuvxsAaGiHA2xd0RVm2Mrx-gQtdPqtbZPuQcH7k64Z_EOQBgiGTgVjucyHD6zBijr_P-
2mhIxuecNSw

2 - Making a Request for an Access Token

After generating the signed JWT, an application can use it to request an access token. The access token request is a POST HTTPS request, and the body must be URL encoded. The URL is as follows:

https://identityhomolog.acesso.io/oauth2/token

The parameters below are mandatory in the request:

POST /oauth2/token HTTP/1.1
Host: identityhomolog.acesso.io
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-
bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY
291bnRfbmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsInN1YiI6InVzZXJfaWRlbnRpZmllciIs
ImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb3BlIjoiKiIsImV4cCI
6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.TjH-mTtwP6tBB93O1sDPaAA6yUF7N2-HZDlpIPz
bf_dxO8A6KZuRWG8ZnICrxX56qj0HREiMlYy27XJgxowrUa0JHvbqc8HJkT7-6Mh7J67UnubZKG1-hi
6jDtkC9BIXBcOhtkNUfZvZetXjLzsRsSDkqxdMtzYZwkRlocvaxL5QXiQhweeEwK_Ux81Adh3z0EIhT
yl7CKJLJ69PuHS7s9IdrjUl79owipp4LF1FvtMhoe7YIL69ohPgFqSv_-Y9qpPdW6be3OEAyKlOM08S
ZBbHBwW4XMvw3uZjTY1sgJ4cBoxrftDpjYOw34oPOKxirqc5-90uOCYe1O1hRtG45w

If the JWT and the access token request were properly formed and the service account has the necessary permissions, then the response from the authentication platform returns a JSON object containing an access token. Here’s an example of a response from the platform:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": "3600"
}

4 - The duration of the access token

The duration of the access token is variable. Its duration is specified in the "expires_in" field, returned along with the access token. The same access token should be used during its validity for all calls to the product APIs.

Do not request a new access token until the validity of the current token is nearing its end. We recommend a margin of 600 seconds (10 minutes). To do this, perform the calculation:

decoded token:
new Date(token.exp - 600)

Where token.exp is the timestamp of the token's expiration.

Examples:

Standard scenario:
expires_in: 3600 (1h) - Token generation at 2:42 PM

Request a new token only at 3:32, that is, 2:42 + (3600 - 600)

Scenario with altered duration:
expires_in: 7200 (2h) - Token generation at 2:42 PM

Request a new token only at 4:32, that is, 2:42 + (7200 - 600)

A new access token can be requested when there are 10 minutes left until expiration.

• ¹ According to RFC 4648 for BaseN encoding, the Base64url format is similar to the Base64 format, except that the character = should be omitted, and the characters + and / should be replaced with - and _, respectively.

Below, you will find a detailed explanation of how each capability works:

Liveness

When there is a need to verify if the person is real and alive at the time of the operation, it can be used either independently or in conjunction with the capabilities of Identity Verification, Behavior Alert, Risk Score, and Validation (1:1). It should always be used in conjunction with the SDKs.

The possible responses are:

• YES: indicates that the user is alive at the moment the selfie is captured.

• NO: indicates that the user is not alive at the moment the selfie is captured.

Identity Verification

When there is a need to ensure that the user performing the process is who they claim to be, it is by default always used in conjunction with the Liveness capability.

The possible responses are:

• YES: indicates that the face belongs to the actual holder of the CPF (Cadastro de Pessoas Físicas).

• NO: indicates that the face does not belong to the actual holder of the CPF.

• INCONCLUSIVE: indicates that there is insufficient evidence to determine whether the face belongs to the actual holder of the CPF.

Behavior Alert

The Behavior Alert complements the Identity Verification response by adding the behavior component, which provides certainty about a risk associated with that identity, based on previous fraudulent behavior. It can only be used in conjunction with the Identity Verification capability.

The possible responses are:

• YES: indicates that the face has been involved in fraudulent identity transactions.

• INCONCLUSIVE: indicates that there is insufficient evidence to suggest that the face is involved in fraudulent transactions in our database.

Risk Score

When there is a need to obtain a probability score about whether the user performing the process is who they claim to be, it can only be used in orchestration with the Identity Verification capability when the response is "INCONCLUSIVE."

The possible responses are:

• Positive Score: can range from +10 to +100. The higher the score, the greater the probability that the face belongs to the actual holder of the CPF. (Cadastro de Pessoas Físicas).

• Zero Score: indicates a registration error. We recommend a new capture be taken.

• Negative Score: can range from -10 to -100. The lower the score, the greater the probability that the face does not belong to the actual holder of the CPF.

Validation (1:1)

When there is a need to recognize if the person in the operation is the same one who completed the registration, it is by default always used in conjunction with the Liveness capability. It can only be used in cases where an Identity Verification process has already been completed.

The possible responses are:

• YES: indicates that the face performing the transaction is the same as the one that completed the process used as a reference.

• NO: indicates that the face performing the transaction is not the same as the one that completed the process used as a reference.

Document Capture and Reuse

When there is a need to request, store, and reuse documents, we offer the ability to leverage users' personal documents (Passport, CIN, RG, and CNH—both digital and physical), reducing friction. If we do not have the documents in our database, it is possible to capture them.

This capability can only be used in conjunction with the Identity Verification capability. For document validation, we use the following technologies:

• Typification: indicates whether the provided document is valid or not.

• OCR: involves extracting data from the document based on an image.

• FaceMatch: involves comparing the face in the selfie with the face on the document.

• CPF Match: involves searching for a specific CPF in the provided document.

Electronic Signature

When there is a need to use biometrics to sign a document, utilize the same method of user authentication throughout the journey to finalize the operation with the contract signature.

*The electronic signature capability is only available through the by Unico integration mode in flows that involve other capabilities.

Serpro Similarity Return

The Serpro similarity return is not a native capability of IDCloud but rather an additional feature incorporated to comply with a regulation from Dataprev concerning INSS payroll credit operations aimed at retirees and pensioners.

Since these operations require the SERPRO similarity return, the IDCloud platform has been adjusted to include this functionality as an option in the product. When using the SERPRO similarity feature, the API response will be the score of similarity.

• When Serpro finds the face, it returns a score from 0-100, as in the example below:

"government": {
        "serpro": 93.0
    }

• When Serpro does not find the face, the score -1 is returned, as in the example below:

"government": {
        "serpro":-1
    }

• When there is an error in the integration with Serpro, the score -2 is returned, as in the example below:

"government": {
        "serpro":-2
    }

To understand how you can use each of the capabilities, be sure to visit the "Integration Methods" section at the link below:

To use server-to-server interactions, you need to request the creation of a service account through the project manager responsible for your company by providing the following information: company name, application name, name, email, and phone number of the person responsible for the application within the company. Separate accounts are required for the Homologation and Production environments.

Once this information is received, a service account responsible for authenticating your application will be created, and an email will be sent to generate the key pair for the account.

A service account credential includes a unique account name, a company identifier (Tenant ID), and at least one key pair (public and private). After generating the keys, you will only receive the private key (a .key.pem file) along with the payload that must be used to construct the JWT. This payload will follow the format below:

If you need the public key to configure it in your system, contact the project manager responsible for your account. It is also possible to generate a public key using the following openssl command:

Download the file below, import it into Postman, and replace the values of the parameters "service_account," "tenant_id," and "secret_key" to test the request.

Introduction

In this section, you will find detailed documentation on how the Process Creation endpoint works in by Unico. Note that to utilize the capabilities of the IDCloud platform in this integration method, you only need to change the value of the "flow" parameter when creating the process. Unico will handle the orchestration of all the desired capabilities.

Learn more about using capabilities in by Unico in the Overview section.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

Process Creation

The errors returned in the request can be identified by the codes below and have the following structure:

Requests separated by flows

Other ways to make a request

by Unico

For companies that wish to have a partner to manage the user experience with best practices and privacy, as well as the ease of orchestrating flows with Unico's capabilities and automatic technology updates, such as SDKs.

With by Unico, you will have a team of security experts and UX design best practices to ensure the best possible conversion in your operation. It can be used responsively on both Desktop and Mobile. Offering the following usage possibilities:

Check out the end-user experience with by Unico in Messaging, Webview, and iFrame, respectively, in the tabs below:

by Client

For companies that wish to control the user experience with their own frontend, as well as build flows using Unico’s capabilities on the backend alongside other technologies and resources used for authentication.

With by Client, you have the freedom you need to create and manage the end-user journey as you see fit, leveraging the capabilities of the Unico IDCloud platform as necessary.

Here are the articles in this section:

Introduction

In this section, you will find detailed documentation on how the Signed Document Retrieval endpoint works in by Unico. This endpoint will provide the signed document of the end user in flows that have the Electronic Signature capability.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

Obtaining the Signed Document

Exemplo de um documento gerado:

Introduction

In this section, you will find detailed documentation on how the Signed Document Proof Set Retrieval endpoint works in by Unico. This endpoint will provide the proof set of the end user's signature in flows that have the Electronic Signature capability.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Obtaining the Evidentiary Set of the Signed Document

Example of a generated document:

The evidential set is a .pdf document containing authentication evidence of a user who underwent identity validation at by Unico.

Below, you will see how this document is represented, as well as the specification of its return fields:

Evidence Set Fields (click on each to learn more)

These evidences can be used to ensure the authenticity of the process.

Introduction

In this section, you will find detailed documentation on how the Process Result Query endpoint works in by Unico.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

Process Result

The content returned in the process.services.documents.doc.data parameter, referring to the OCR Extraction technology, can be consulted below:

Introduction

In this section, you will find detailed documentation on how the Get Evidence Set endpoint works in by Unico. This endpoint will provide the evidence set of the completed biometric transaction, allowing you to store it for possible future disputes by the end user.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

Obtaining the Evidentiary Set

Introduction

In this section, you will find detailed documentation on how the Get User Selfie endpoint works in by Unico. This endpoint will provide the user's selfie, with a watermark, from completed processes, allowing you to use it as support in cases of disputes by the user.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

Obtaining User Selfie

by Unico's customization options allow you to tailor its interface to your company's visual identity and create a personalized user experience.

Available customizations:

Logo Customization

You can customize the logo displayed to users who access by Unico journeys. This customization reinforces the partnership between your company and Unico, indicating that the verification is performed by Unico at the request of the client or partner.

To request the inclusion of the logo, send the Unico team a URL where the logo is hosted in an online directory (i.e., the logo must be accessible via URL in the browser).

Unaccepted logo formats

Customizing the color and shape of buttons

Customize the by Unico action buttons. Define the text color, background, and border radius of the button to reinforce your company's visual identity.

Rounding the button corners

In addition to text and background colors, you can also define the button's corner rounding (border-radius) in pixels, according to the scale below:

Customization settings

To configure the visual identity of the client or partner for the button, share the following information with Unico's implementation team:

• Hexadecimal code for the button background color.

  • Example: #000000.

• Hexadecimal code for the button text color.

  • Example: #ffffff.

• Button corner rounding (border-radius) in pixels.

  • Example: 10px.

Customization of the contextualization screen

The by Unico contextualization module allows the client or partner to provide information about the verification, such as the requesting company, reason, and value of the operation, making the process more secure.

The section of the request to be modified is as follows:

How to start

To use by Unico through the Unico Web SDK, the first step is to register the domains, always using the HTTPS protocol, that will be used as hosts to display the user journey experience.

To begin using the SDK, we should start with the installation of the Unico web SDK:. by Unico uses the same SDK that is used for IDPay:

Available methods

The sequence diagram below demonstrates how to use the SDK and the API result from by Unico to configure the iFrame:

Opt for the Iframe Solution with Auth Token Instead of CSP

After careful analysis of our needs and challenges, we have decided to adopt a solution based on iframes with authentication tokens rather than implementing a Content Security Policy (CSP). This choice was motivated by various considerations related to the security and flexibility required to meet our clients' demands.

Context and Challenges with CSP

Content Security Policy (CSP) is a powerful tool for protecting web applications against various types of attacks, such as Cross-Site Scripting (XSS) and code injection. However, when configuring a CSP policy, it is necessary to define a strict list of trusted domains. This approach is effective when the domains are fixed and predictable. However, for our clients, who often use dynamic and variable domains, this rigid configuration presents significant challenges.

Vulnerability with Dynamic Domains

Dynamic domains pose a substantial security risk when using CSP. When a client has domains that frequently change or are created dynamically, it would be necessary to constantly update the CSP policy to include these new domains. This not only increases maintenance efforts but also exposes the domains to which the CSP policy applies. Each domain added to the CSP policy is potentially a vulnerability point if not adequately managed.

Solution with Iframe and Auth Token

To mitigate these risks and meet the flexibility required by our clients, we opted to use iframes combined with authentication tokens. This solution provides an additional layer of security and avoids the need to expose or manage an extensive and dynamic list of domains.

How It Works

• Secure Authentication: Each iframe is loaded with a unique authentication token for each transaction, ensuring that only authorized users can access the content. This token is verified in real-time, providing an additional layer of security and control.

• Content Isolation: The use of iframes allows for the isolation of content in a separate context, reducing the risk of interference between different origins and mitigating potential attacks.

• Flexibility for Dynamic Domains: By not relying on a static CSP policy, our solution easily adapts to our clients' dynamic domains without the need for constant updates to security policies.

he userRedirectUrl field is used to direct the user. This field is received in the success response of the process creation when making the CreateProcess request.

Here you will find three ways to manage the user experience in web applications:

Introduction

The IDCloud platform uses conventional HTTP response codes to indicate the success or failure of an API request.

As a general rule:

• Codes in the 2xx range indicate a successful request;

• Codes in the 4xx range indicate incorrect or incomplete parameters (for example, a required parameter was omitted, or an operation failed with third parties, etc.);

• Codes in the 5xx range indicate that there was an error on the Unico IDCloud platform's servers.

The Unico IDCloud platform also generates an error message and an error code formatted in JSON:

Possible Errors

In this topic, you will find the possible errors for the endpoints, separated by their HTTP response.

Create Process

Consult Process Result

Get User's Selfie

Obtain Evidence Set

Obtain Signed Document

Obtain Evidence Set of the Signed Document

The following project examples are provided to facilitate understanding of how Unico works.

PoCs in a native environment

PoCs in a web environment

By Unico provides the QR code functionality to facilitate the flow on desktop devices. Through the QR code, it is possible to start the By Unico in a web experience without having to worry about whether the user's device has a camera or not. In this way:

• We reduce the chance of failure in biometric capture;

• We ensure a better experience in other capabilities;

• We increase the chances of conversion.

How does it work?

When the user starts By Unico through a desktop device:

We identified that it's a desktop device and provided the QR code so the user can continue the journey on their mobile:

Once scanned, the user continues their journey on the mobile as usual, while the desktop device waits for the completion:

The desktop device detects that the journey was completed on the mobile and redirects the user to the originating experience:

Device qualification criteria as a desktop

• Screen size: minimum width of 961px;

• Screen orientation: landscape;

• User-Agent: must not be a mobile device.

Introduction

by Client is a channel that offers complete freedom for the client to use the identity validation solutions from the IDCloud platform.

You can combine capabilities as you wish and for the most distinct use cases, but to do so, you will need to have API Keys configured with the capabilities you wish to use.

*It is also possible to use the by Client feature to process your face database. To do so, please contact your account manager, who will guide you through the necessary procedures for this process.

Synchronous and Asynchronous Capabilities

In by Client, we have capabilities where the response is synchronous (i.e., the response is returned when the process is created) and other capabilities that are asynchronous (where we process the data and you need to "fetch" the result through a GET method in the REST API).

In your operation, you can combine the capabilities as you wish, but each capability will have its own communication method. For example:

• You can have an operation that uses the Identity Verification + Behavioral Alert + Risk Score capabilities;

• When creating the process, the response for the Identity Verification and Behavioral Alert capabilities will be synchronous, provided in the response of the process creation API;

• However, the Risk Score capability will be executed asynchronously, requiring you to wait for its processing and then make another GET request to obtain the final result of the process.

Below, see the synchronous and asynchronous capabilities:

Synchronous Capabilities

Liveness:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "liveness": 1
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "liveness": 2
}

Identity verification:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "yes"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "no"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  }
}

Behavior Alert:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "yes"
  }
}

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "inconclusive"
}

Validation (1:1)

{
    "authenticated": "true"
}

{
    "authenticated": "false"
}

Document Capture and Reuse:

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "status": 3,
  },
  "document": {
    "id": "b97c3fd9-d95d-413f-bc0a-75eb87304421",
    "type": "CNH",
    "cpfMatch": false,
    "content": {
      "numero": "044589731564",
      "rgNumero": "123456789 SESP PR",
      "nomeCivil": "Homer Simpson",
      "filiacao": [
        "Monasimpson",
        "Monasimpson"
      ],
      "dataNascimento": "1990-05-12T00:00:00Z",
      "dataHabilitacao": "1997-11-18T00:00:00Z",
      "dataExpiracao": "2017-12-07T00:00:00Z",
      "dataEmissao": "2012-12-07T00:00:00Z",
      "localEmissao": "Curitiba PR",
      "categoria": "B",
      "renachNumero": "PR904987581"
    },
    "fileUrls": [
            "https://url-signer-1",
            "https://url-signer-2"
        ]
  }
}

Asynchronous Capabilities

Identity verification:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "yes"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "no"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  }
}

Risk scoring:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "score": 50
}

Behavior Alert:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "yes"
  },
  "faceWithOtherId": {
    "result":"yes"
  }
}