# Consuming identity-verification results

Truora Pass is the verifier: the user completes document and face verification **inside Truora Pass**, not in your application. Your application never runs a verification itself — it reads the outcome as claims from the [UserInfo endpoint](/truora-pass/userinfo_and_claims/), scoped to what the user consented to share.

This guide explains which scopes and claims carry the verification outcome and how to gate access on them.

## Verification claims by scope

### `identity` scope — is this person verified?

| Claim | Values | Meaning |
|---|---|---|
| `identity_verified` | `true` / `false` | Whether the user's primary identity document is valid |
| `verification_level` | `basic`, `none` | Level of identity verification achieved |
| `is_risky` | `true` / `false` | Whether risk signals were detected for this user |
| `was_manually_reviewed` | `true` / `false` | Whether the user's verification went through manual review |

The `identity` scope also releases the verified person's details: `given_name`, `family_name`, `birthdate`, `nationality`, and the primary document's `document_number`, `document_type`, and `issuing_authority`.

Document expiry: when the primary document is verified **and** expired, the response additionally includes `document_expired` (`true`) and `expiration_date`. If you need every verified document rather than just the primary one, request the `documents` scope, which releases the `documents` array (`document_type`, `document_number`, `country`, and `date_of_birth` when available, for valid documents only).

### `verification` scope — how and when was it verified?

| Claim | Values | Meaning |
|---|---|---|
| `verification_status` | `full`, `partial`, `none` | `full` = both document and face verified; `partial` = one of the two; `none` = neither |
| `verification_methods` | array with any of `document`, `face` | Which verification methods the user completed |
| `verification_date` | RFC 3339 timestamp | When the verification happened (present when available) |

### `background` scope — background-check outcome

| Claim | Values | Meaning |
|---|---|---|
| `trust_level` | `high`, `medium`, `low`, `not_available` | Trust level from the user's background check |
| `background_verified` | `true` / `false` | Whether a background check has been completed |

**Note**: when the `background` scope is granted, Truora Pass refreshes the background information before answering the UserInfo call, so `trust_level` reflects the latest available result. In the [CIBA flow](/truora-pass/ciba_flow/), `background` (like `documents`) is a sensitive scope and requires a `binding_message` — see the [Scopes reference](/truora-pass/scopes_reference/).

### `biometric` scope — face signals

| Claim | Values | Meaning |
|---|---|---|
| `face_enrolled` | `true` / `false` | Whether the user has enrolled a face in Truora Pass |
| `liveness_check_passed` | `true` / `false` | Whether the user passed a liveness check |

The `biometric` scope releases additional claims (`last_face_verification_date`, `face_match_confidence`, `quality_level`, `verification_method`) — see the full table in [UserInfo and claims](/truora-pass/userinfo_and_claims/).

## Recommended integration pattern

1. Request the `openid identity verification` scopes in your authorization request (add `background` if your use case needs the trust level).
2. Complete the [Authorization Code flow](/truora-pass/authorization_code_flow/) and call `GET /v1/oauth2/userinfo` with the access token.
3. Gate access on the combination of `identity_verified` and `verification_status`:

```javascript
const response = await fetch('https://api.pass.truora.com/v1/oauth2/userinfo', {
  headers: { Authorization: `Bearer ${accessToken}` },
})
const claims = await response.json()

const accepted =
  claims.identity_verified === true &&
  claims.verification_status === 'full' // accept 'partial' for lower-assurance use cases

if (accepted && claims.is_risky !== true) {
  // grant access
}
```

If the user has not completed verification yet (`verification_status` is `none` or `identity_verified` is `false`), direct them to finish the process in Truora Pass and try again — verification always happens inside Truora Pass, never in your application.

## Example UserInfo response

A user who completed both document and face verification, with the `openid identity verification background biometric` scopes granted:

```json
{
  "sub": "WLT_USR_01ARZ3NDEKTSV4RRFFQ69G5FAV",
  "identity_verified": true,
  "verification_level": "basic",
  "given_name": "Ana",
  "family_name": "García",
  "birthdate": "1992-04-15",
  "nationality": "CO",
  "document_number": "1032456789",
  "document_type": "national_id",
  "issuing_authority": "Registraduría Nacional",
  "is_risky": false,
  "was_manually_reviewed": false,
  "verification_status": "full",
  "verification_methods": ["document", "face"],
  "verification_date": "2026-06-28T14:03:22Z",
  "trust_level": "high",
  "background_verified": true,
  "face_enrolled": true,
  "liveness_check_passed": true,
  "face_match_confidence": "not_available",
  "quality_level": "not_available",
  "verification_method": "photo"
}
```