Proof of Presence

​

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. 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 — recommended for returning-user checks.
• Integrate a one-time check — use a uniqueness request.

​

How it works

Use the Selfie Check (selfieCheck) preset in IDKit to request this credential. See Configure Credentials 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 for the complete integration flow. Testing your integration? See Testing Selfie Check in Sandbox for coverage, critical user journeys, and known limitations.