Trust Reuse

What it is

When a user verifies with Stile at one operator, they can opt in to share that verification with other operators on the platform. If a returning user shows up at your application — and they've previously verified with another Stile operator, and they consented to share — your verification session is marked as verified instantly, no camera, no ID upload.

This is opt-in on both sides:

• The user explicitly consents on the success screen of their first verification ("Save my verification for use at other Stile operators")
• The operator explicitly opts in in their Trust Reuse settings to accept reused verifications

If either side hasn't opted in, the user goes through the normal verification flow at your application — exactly as they would today.

Why use it

• Lower abandonment — returning users skip a 60–120 second camera + ID flow
• Same trust level — you only accept verifications that match your method, jurisdiction, and recency policy
• You're not on the hook for someone else's bad data — you set the acceptance bar (max age, allowed methods, jurisdiction lock); credentials that don't meet your bar fall through to fresh verification automatically
• Full audit trail — every accepted grant has its source operator, source credential, method, and timestamps recorded against your org

Enabling Trust Reuse for your application

In the dashboard, go to Settings → Trust Reuse. You'll see:

How it shows up in your flow

You don't need to change any code to participate. After enabling Trust Reuse:

1. Your existing POST /v1/verification_sessions calls work exactly the same — same request, same response shape
2. When the user happens to qualify for reuse, the session is created with status: "verified" immediately, instead of status: "created" (which would normally wait for the camera flow)
3. The standard verification_session.verified webhook fires
4. Optionally, you also receive a trust_reuse_grant.created webhook — see below

If you want to be aware of which path was taken, look at session.verification_path on the retrieved session — it'll be "trust_reuse" for reused sessions vs. the method name (e.g. "document_capture") for fresh verifications.

Webhook events

Subscribe to these in Settings → Webhooks to receive structured signals about Trust Reuse activity affecting your application:

trust_reuse_grant.created

Fires when a reuse grant is created for your application. The data.object contains:

{
  "object": "trust_reuse_grant",
  "id": "trg_...",
  "source_org_id": "org_...",
  "target_org_id": "org_yours",
  "session_id": "vks_...",
  "verified_person_id": "vp_...",
  "method": "DOCUMENT_CAPTURE",
  "age_tier": "MIN_AGE_21",
  "strength": "DOCUMENT_CAPTURE",
  "granted_at": "2026-05-12T10:00:00Z",
  "expires_at": "2027-05-12T10:00:00Z",
  "revoked_at": null,
  "revoked_reason": null
}

You'd typically log this for compliance audit and treat it as equivalent to a fresh verification_session.verified event.

trust_reuse_grant.revoked

Fires when an accepted grant is revoked. Common reasons:

• USER_REVOKED — the user clicked the revoke link in our notification email
• USER_REVOKED_CONSENT — the user pulled all sharing across all operators, which includes your grant
• ERASURE_REQUEST — the user was erased from the platform; their verification is gone everywhere
• TARGET_OPERATOR_REVOKED — you yourself revoked this grant via the dashboard or API
• SOURCE_CREDENTIAL_REVOKED — the source operator removed the underlying credential

You should treat the user as no-longer-verified for future actions. Past sessions are not retroactively invalidated.

trust_reuse_consent.revoked_by_user

Fires when the user revokes their sharing consent platform-wide. Sent to every operator currently holding a derived grant. If your downstream system caches "this user is verified," this is your cue to clear it.

Revoking access from your side

In Settings → Trust Reuse → Accepted grants, you can revoke any individual grant. Revoking does:

• Marks the grant as revoked in our ledger
• Fires trust_reuse_grant.revoked to your webhook endpoint (closes the loop with your downstream systems)
• Does not invalidate any verification sessions already marked verified — those are historical facts; future reuse with this person won't fire

What the user sees

After a successful first verification (at any Stile operator), the user sees a single optional checkbox on the success screen:

Save my verification so other operators don't have to re-verify me.

Default is unchecked — they have to actively opt in.

If they do opt in, every time a future operator accepts a reuse grant from their consent, the user gets a transactional email from us:

Acme Carrier just used your existing Stile verification. If you didn't expect this, click here to revoke their access.

The link in the email is a one-shot signed URL — one click revokes the specific grant, with no login, no password, no account page. They can also "revoke all sharing" from the same email to pull consent platform-wide.

Operator-to-operator privacy

Trust Reuse is designed so that you can never learn anything about which other operators a user has been verified with unless the user explicitly tells you (by getting reused at your application). Specifically:

• You cannot enumerate which users have been verified elsewhere
• A failed reuse attempt (any decline reason) is internally indistinguishable from a user who has never been on the platform — both fall through to fresh verification with identical observable behavior
• The cross-operator anchor table (verified_persons) is accessible only via narrow SECURITY DEFINER functions that return existence booleans, not row metadata

Frequently asked questions

Will this affect my SOC 2 attestation? No. Trust Reuse runs entirely within our existing platform compliance model. Reuse activity is recorded in your org's audit log; you have full visibility into who accepted what and when.

Can I see the user's original verification details? You see the method, age tier, strength, source operator id, and timestamps — same as any other verified session. You don't see the user's name, ID document, or face image — those stay with the source operator and aren't part of the reuse.

What happens if a user's source verification is found to be fraudulent? The source operator revokes the credential → we cascade-revoke all derived grants → you receive trust_reuse_grant.revoked with reason SOURCE_CREDENTIAL_REVOKED. You should prompt the user to re-verify on their next action.

Can I require fresh verification for certain high-risk use cases? Yes. Trust Reuse only applies at session creation time. If your business logic decides this particular session is high-risk (large transaction, new device, suspicious IP), you can explicitly create a session with accept_existing: false to force fresh verification regardless of any active grants.

Is there a per-method tier hierarchy? Yes. A DOCUMENT_CAPTURE credential satisfies a request for SELF_ATTESTATION (because document capture is strictly stronger), but not vice versa. A MIN_AGE_21 credential satisfies a MIN_AGE_18 request. Recency is independent — a 10-day-old DOCUMENT_CAPTURE won't satisfy your policy if you set max-age to 7 days.