The application must wait for the user to complete the Proof, then obtain and analyze the results.

Proof Status

When the user completes Proof, the status changes from 0 - Pending to 1 - Accepted, and the results are ready to be picked up immediately. Refer, to the Transaction Status section for more details.

📘

Common Transaction Status

The Transaction Status is common between Proof (Identity Verification) and Verified (Authentication) workflows.

The application has several ways to detect when the status changes.

• Periodic poll of backend for Proof operation status change using Operation Status Endpoint
• Embedded Integration can listen to Web Component Events for web integration or to JavaScript bridge events for WebView integration. The UI emits the signal that the user has reached the "final page" of the experience.

Please refer to the Web Component Events section for more details.

The best strategy from both a UX transition reaction time and system load perspective is to:

• Listen to events from the Web Component / WebView.
• When the user reaches the final page, pass the signal from your application frontend to your application's backend.
• Confirm the status change via the backend Operation Status Endpoint.
• As a backup, poll status changes periodically using Operation Status Endpoint, for example, once every 5 seconds.

Both Out-of-band and Embedded integrations can use Webhook to receive notifications when the status changes. Note that webhooks are not queued and do not have guaranteed delivery, so the periodic polling backup strategy still applies.

Get Proof Results

When Proof status is 1 - Accepted the results are ready to be retrieved using Operation Result Endpoint

The application needs to ingest and inspect the results, the beginning part of the Proof Results v2 sample JSON is shown below:

{
    "Name": "GetForeignIDDocument",
    "OperationId": "e09febaa-3b64-b632-1236-4f491d48b47c",
    "Payload": {
        "Data": {
            "VerificationSteps": {
                ...
            },
            "Document": {
                "Description": "Document Image",
                "Type": "2",
                "CapMethod": 2,
                "RawData": [
                    ...
                ],
                "Data": [
                    {
                        "Key": "Page1Name",
                        "Value": "United States - Georgia Driving License (2019) Real"
                    },
                    {
                        "Key": "Page1Probability",
                        "Value": "0.96807367"
                    },
                    {
                        "Key": "Page2Name",
                        "Value": "United States - Georgia Driving License (2019) Side B"
                    },
                    {
                        "Key": "Page2Probability",
                        "Value": "0.9040118"
                    },
                      
                    ...

Results JSON Values Description

The Proof result object schema can be inspected at Proof Result - GetIDDocument API Swagger UI endpoint description.

For V1 legacy API, the information is located in the Data object. If developers follow the guide for the current V2 version of the API, the information is located in the Payload.Data object.

Payload.Data contents reference:

The top-level JSON object also contains additional elements:

• Metadata contains elements that are kept in the audit trail after PII is removed
• Tag contains the tag element that can be provided via API during transaction initialization, and can be used for tracing /reporting purposes.

🚧

Warning

The key case for padResultand mismatchMrzOcrmay change from the camelCase to PascalCase in subsequent releases.

Save Proof Results

authID only retains user-provided documents and other PII data for 7 days.

Developers can choose to parse and save individual objects/keys into the permanent storage of the user application (user database).

Developers can also get a pre-formatted PDF of Proof details with all PII data, as displayed in the Identity Portal, using the dedicated authID Reports API. Use the Ledger formatting option when generating Proof report PDF as the default choice may have margin/formatting issues.

Inspect Proof Results

The logic deciding if a user can proceed with onboarding must be taken into account in the following checklist.

Proof Results Suggested Decision Matrix​

The following table suggests the application logic to determine if the user must be allowed to proceed with enrollment/onboarding.

🚧

Developers Must Impletment Decision Logic

authID does not provide an automatic decions based on the outputs of signals from the Proof process. Developers must code their own decision logic that properly accounts for failed signals that indicate fraud.