Returning User Verification

Overview

Most verification systems force users through the full camera + ID scan flow every time they visit. Stile takes a different approach: verify once, then issue a reusable signed proof (a VP token) that lets the user skip re-verification on subsequent visits.

This dramatically reduces friction for returning users while maintaining the same security guarantees.

Three-tier reverification flow

When a user arrives, the system checks three tiers in order. The first tier that succeeds is used — no unnecessary steps.

Tier 1: VP token (localStorage) --> instant pass, zero friction
          |
          | (no token or token invalid)
          v
Tier 2: Server lookup by email --> OTP ownership proof --> credential reuse
          |
          | (no credential found or credential expired)
          v
Tier 3: Full verification --> camera, ID scan, selfie

VP tokens

A VP token is a signed JWT stored in the browser's localStorage, scoped to the current origin. It is issued automatically after a successful verification.

What's inside

The token contains:

• A verified person ID (opaque identifier)
• The credential method and age tier
• An expiry timestamp
• A signature from Stile's servers

How it works

1. User completes verification (Tier 3) or OTP flow (Tier 2).
2. Stile issues a VP token and the widget stores it in localStorage.
3. On the next visit, the widget finds the token and sends it to Stile for validation.
4. If valid, the user passes instantly (Tier 1) — no camera, no OTP, no friction.

Cross-site credential reuse

VP tokens are stored in localStorage, which is scoped per origin. A token from shop-a.com is not accessible on shop-b.com.

Cross-site reuse works through email/phone lookup + OTP (Tier 2):

1. User visits shop-b.com for the first time (no local VP token).
2. User enters their email address.
3. Stile finds an existing credential linked to that email (verified on shop-a.com).
4. User completes an OTP challenge to prove they own the email.
5. Stile issues a new VP token for shop-b.com — no camera or ID scan needed.

Email binding

VP tokens are bound to the email address used during verification. This prevents token sharing:

• If user A verifies with alice@example.com, their VP token is bound to that email.
• If user B tries to use the same device, a different email triggers re-verification.
• Changing the email on an existing session forces a full Tier 3 verification.

Credential strength ranking

Not all verification methods carry the same weight. Stile ranks credential methods by strength:

A stronger credential always satisfies a weaker requirement. For example, a user verified with document_capture (rank 5) can satisfy a request that requires self_attestation (rank 1) without re-verifying.

The reverse is not true — a self_attestation credential cannot satisfy a document_capture requirement. In that case, the user must complete a step-up verification.

Age tier compatibility

Age tiers follow a simple hierarchy:

over_21 --> satisfies over_18 and over_16
over_18 --> satisfies over_16 only
over_16 --> satisfies over_16 only

A credential proving over_21 automatically satisfies any over_18 or over_16 requirement. A weaker tier (e.g. over_16) cannot satisfy a stronger one (e.g. over_21).

Credential expiry

Credentials have an expiry based on jurisdiction compliance rules. The default expiry is 365 days from the date of verification.

When a credential expires:

• Tier 1 (VP token) stops working — the token is rejected during validation.
• Tier 2 (email lookup) finds the credential but sees it's expired.
• The user is routed to Tier 3 for a full re-verification.

Step-up verification

Even if a user has a valid, non-expired credential, they may need to re-verify if the new request requires a stronger method.

Example: A user verified with self_attestation (rank 1) visits a site that requires document_capture (rank 5). Their existing credential doesn't meet the requirement, so they must complete a new verification with the stronger method.

After the step-up verification, the new (stronger) credential replaces the old one. The user now has a document_capture credential that satisfies both document_capture and self_attestation requirements.

OTP is not proof of age

A common misconception: completing an OTP challenge does not prove anything about the user's age or identity.

• OTP proves: "This person controls this email address."
• OTP enables: Reuse of an existing, previously-verified credential.
• OTP does not prove: Age, identity, or anything else.

The actual proof comes from the underlying verification credential (ID scan, facial age estimation, etc.). The OTP is a gate that ensures only the rightful owner of the email can access the credential linked to it.

Related

• Testing & Sandbox — using skip_verification to test returning-user flows
• Security Best Practices — webhook verification and anti-spoofing
• Webhooks — handling verification_session.verified events