> ## Documentation Index
> Fetch the complete documentation index at: https://tfh-takis-world-id-marketing-names.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof of Presence

> A medium-assurance biometric credential using the device camera for liveness and facial similarity.

| Property | Value |
| - | - |
| Issued by | [Tools for Humanity](https://www.toolsforhumanity.com) (verified issuer) |
| ID | `11` |
| Validity period | 90 days (the default duration of the credential; generally the maximum recommended sybil resistance window) |

## Introduction

Proof of Presence is the credential used by Selfie Check in IDKit.

Selfie Check uses the user's mobile device camera for liveness and facial
similarity checks. It adds friction against automated and repeated account
creation without requiring a Proof of Human. Unlike high-assurance Orb verification,
Proof of Presence does not provide a strict one-person-one-account guarantee and is
considered a medium-assurance verification method.

Use Proof of Presence for:

* **Liveness detection:** Confirm the user is a real person, not a spoof or injection attack.
* **Abuse resistance:** Add friction to automated and repeated account creation.
* **Continuity:** Confirm a returning user is the same person who originally enrolled.

Proof of Presence has a 90-day inactivity window. After 90 days without use, the
user completes the camera flow again before returning another proof.

Anyone with World ID App can use Proof of Presence. No Orb, passport or
other prerequisite credential is required.

## Uniqueness Risk Signal

Each Selfie Check response includes a versioned `sybil_score` that
can help an app assess the risk of repeated enrollment. It is a risk signal, not
a uniqueness verdict, and should be considered alongside other evidence. The
response also includes an `integrity_bundle` that lets the Developer Portal
verify it came from an authentic World ID App.

### Understanding Sybil Score

The score measures how far the observed number of face matches exceeds the number expected from the model’s False Match Rate (FMR), expressed in standard deviations. A higher score indicates more matches above that baseline and a stronger signal of possible repeated enrollment.

At enrollment, the new face’s embedding is compared privately against the existing embeddings in the database. The number classified as a match is `match_count`. The FMR is the probability that the model incorrectly matches two different people.

For a database containing `db_size` entries, the expected number of false matches is `db_size × FMR`. Under the model’s assumptions, the standard deviation is `√(db_size × FMR × (1 − FMR))`.

The raw score is calculated as:

$$
z = \frac{\text{match\_count} - \text{db\_size} \times \text{FMR}}
{\sqrt{\text{db\_size} \times \text{FMR} \times (1 - \text{FMR})}}
$$

The returned score is clipped to the range `0` to `10`: negative values are returned as `0`, and values above `10` are returned as `10`.

$$
\text{score} = \max(0, \min(z, 10))
$$

**Model assumptions.** This calculation treats `match_count` as following a `Binomial(db_size, FMR)` distribution. It assumes each comparison is independent and has the same false-match probability. It does not account for dependencies between database entries or subgroups whose FMR differs from the population average used in the calculation.

A nonzero match count does not establish that someone is already enrolled, and a low score does not guarantee uniqueness. The score is recalculated at enrollment and each credential renewal, so it can change as credentials enter or expire from the database.

#### Interpreting the score

**Guidance for integrators:** The bands below provide a high-level explanation of the score. They are illustrative risk categories, not validated decision thresholds or probabilities of prior enrollment. Choose and validate your own thresholds based on your application’s risk tolerance, and consider the score alongside other evidence.

| Returned score | Technical interpretation | High-level guidance | Illustrative risk level |
| - | - | - | - |
| **0 to less than 2** | The raw value is below 2 standard deviations above the expected false-match count. Negative raw values are also returned as `0`. | Little or no excess-match signal. This does not establish uniqueness. | Low |
| **2 to less than 4** | The observed count is 2 to less than 4 standard deviations above the expected count. | An elevated signal that may reflect lookalikes or repeated enrollment. Assess alongside other signals. | Medium |
| **4 to less than 6** | The observed count is 4 to less than 6 standard deviations above the expected count. | A stronger excess-match signal. Consider additional verification based on your risk policy. | High |
| **6 to 10** | The raw value is at least 6 standard deviations above the expected count. Values above 10 are capped at `10`. | A substantial excess-match signal that warrants closer assessment. It does not prove prior enrollment. | Very high |

These standard-deviation bands should not be read as normal-distribution confidence levels or as the probability that a person is already enrolled.

## Choose your integration

Use **session proofs** if users need to complete Selfie Check more than once—for
example, when returning to your app or confirming a sensitive action. Create a
session on their first successful verification, then prove that same session on
subsequent checks.

Use a **uniqueness request** when your app needs to allow each user to complete a
particular action once, such as claiming a reward. The one-time nullifier for that
action cannot serve as a reusable verification flow. Proof of Presence remains a
medium-assurance signal; neither flow provides a strict one-person-one-account
guarantee.

* [Integrate with sessions](/world-id/idkit/session-proofs) — recommended for returning-user checks.
* [Integrate a one-time check](/world-id/idkit/integrate) — use a uniqueness request.

## How it works

Use the Selfie Check (`selfieCheck`) preset in IDKit to request this credential. See [Configure Credentials](/world-id/idkit/credentials#selfie-check) for the SDK integration.

* **On mobile (iOS/Android):** Use IDKit to generate a deep link and attach it to a "Verify" CTA. When the user taps it, they are redirected to World ID App to complete Selfie Check.
* **On desktop:** Use IDKit to generate a QR code and display it to the user. When the user scans it with their mobile device camera, World ID App launches and guides them through Selfie Check.

## User Experience Flow

1. **Challenge:** The user initiates the flow on your app (Relying Party).
2. **Hand-off:** The user is redirected to World ID App. If they don't have World ID App installed, they are guided to download it and go straight into the Selfie Check experience.
3. **Enrollment/Auth:**
   * **New User:** Enrolls with a selfie and liveness check.
   * **Returning User:** Completes a short camera check to verify continuity.
4. **Success:** The user returns to your application with a verified credential.

## Next steps

See [Integrate IDKit](/world-id/idkit/integrate) for the complete integration flow.

Testing your integration? See [Testing Selfie Check in Sandbox](/world-id/sandbox/testing-selfie-check)
for coverage, critical user journeys, and known limitations.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.