Identity proofing in your tenant

A labeled simulation

Simulation. Identity proofing in a tenant is a teaching simulation. Applicants choose made-up sample documents, selfies and issuer records. Nobody uploads a real document or photo, the samples carry made-up details, and a result is valid only inside your tenant. Verified claims name the trust framework btl_simulation, so no application can mistake them for a real proofing result.

Everything around the samples is real: the settings change the outcome, referee decisions are recorded with the referee as the actor, records expire and can be revoked, authentication levels enforce them, and tokens carry them.

Turn it on

Open Identity Proofing. Proofing starts off. Under Settings, choose:

• which routes to offer, and the assurance level each one reaches: IAL1, IAL2 or IAL3. Document and selfie and the record check reach at most IAL2; only a referee reaches IAL3;
• whether an inconclusive result from an automated route goes to a referee or fails;
• the face match threshold, from 50 to 99, and the review band below it, up to 30. A score at or above the threshold matches, a score inside the band is inconclusive, and a lower score fails. The threshold minus the band must be at least 40;
• how long a record lasts, from 30 days to five years;
• which claims records verify and release (given name, family name, date of birth), and how much evidence verified claims describe.

People apply on /account/proofing on your tenant's host, linked from Your Profile and Security while proofing is on.

Routes and sample evidence

Each route runs its checks in order and stops at the first failure. Validation checks the evidence, resolution ties it to the account, and verification ties it to the person.

The sample documents carry the account's own name, a made-up date of birth and a made-up document number, the same on every attempt. The letter's code is stored only as a keyed digest; a new letter replaces it.

Referees

Applications that need a person appear under Waiting for a referee for anyone holding tenant.proofing.review. Create a custom role, such as Proofing referee, with that permission on Roles. A referee sees the applicant, the route, the evidence offered and every automated check, then approves or rejects with a reason. Nobody can decide their own application, whatever roles they hold. An approval follows the settings at decision time: the route must still be offered, and the record reaches no more than the route's current level. An application waits up to 14 days.

Records

A verified application writes a record with its route, level, verified claims and a description of the evidence. People keep at most ten records; the strongest current one counts. Records expire at the end of their lifetime and can be revoked with a reason under Proofing records. Revoking one takes effect at once for sign-ins and for every token issued afterwards, including refreshed tokens; tokens already issued keep their claims until they expire. A deleted user's records stop counting at once and are removed shortly after. Applications that finished more than 30 days ago are removed too.

Recovery for someone who cannot sign in

Someone who has lost every way to sign in cannot reach /account/proofing. Recovery proofing gives them a short, help desk controlled way in. Under Settings, Recovery for people who cannot sign in chooses whether the help desk may open recovery requests (off at first, and only while proofing is on), how many hours a request lasts, from 1 to 72 (24 at first), and whether resetting anyone's sign-in methods needs a verified request first.

1. A person holding tenant.proofing.recovery.manage opens User Management and chooses Open recovery proofing on the person's row. The dialog shows a one-time recovery code once. Give it to the person through a channel you already trust, such as a call back to the number on record. Opening a new request ends the earlier one.
2. The person opens /recover on your tenant's host, linked from the sign-in page as Lost every way to sign in?, and enters their email address and the code. The code works once and binds the request to that browser. An unknown address, a person without an open request and a wrong code all get the same answer.
3. On the same page they prove their identity with the routes you offer, exactly as on the account page. A referee decides an application that needs one; the queue marks it as account recovery. Nothing on the page signs anyone in.
4. A verified request lets a help desk reset the person's sign-in methods once, before the window ends. With the requirement on, a reset without one is refused with recovery_proofing_required. Without it, a reset still uses a verified request when there is one, and Audit says so.

The page is public, so it has its own limits: code entries per browser, wrong codes per person (one past the limit ends their request), recovery proofing steps per person, and open requests per tenant, all under Usage and limits on the Overview page. Nobody can open recovery for themselves, opening it needs the permissions the person holds, and BTL users recover their account on the Beyond the Login site instead. The Recovery requests card on Identity proofing lists current requests and those that ended in the last week, with Cancel for current ones; cancelling ends the code and any application in progress.

Levels that need proofing

On Flow Policy, an authentication level can also require identity proofing at an assurance level, which is added to its value: urn:btl:acr:pwd+ial2 means a password sign-in by someone with a current IAL2 or IAL3 record. See Authentication levels.

When a request asks for such a level, the person first meets its sign-in methods, then the tenant sends them to the proofing page with the level named. After a verified application they continue to the application. If they return without one, the level counts as declined: an essential request gets unmet_authentication_requirements, and other requests continue with the level the sign-in did meet. With prompt=none the application receives interaction_required. A level that needs an assurance level no offered route reaches cannot be met. Changes that need such a level, and the sample API's level requirements, check the record the same way.

Verified claims

Claim mappings can copy two proofing attributes: Identity proofing assurance level and Verified claims from identity proofing. Add a mapping named verified_claims with the second attribute in ID Token Management, with a scope if you want only some applications to receive it. An application can also ask for it with the claims parameter, which sends it to the ID token or UserInfo even if the mapping names only the other, but still only when the mapping's scope was granted. The value has the OpenID Connect for Identity Assurance shape:

{"verification": {"trust_framework": "btl_simulation", "assurance_level": "ial2",
  "time": "2026-10-05T09:00:00.000Z", "verification_process": "<record ID>",
  "evidence": [{"type": "document", "check_details": [{"check_method": "vpiruv"}, {"check_method": "bvr"}],
    "time": "2026-10-05T09:00:00.000Z"}]},
 "claims": {"given_name": "Ava", "family_name": "Archer", "birthdate": "1984-07-19"}}

Narrowing the claims or evidence detail in Settings applies to existing records at once. While proofing is on, discovery adds verified_claims_supported, trust_frameworks_supported, evidence_supported, documents_supported and claims_in_verified_claims_supported.

Permissions, history and limits

Each part has its own permission: tenant.proofing.read and tenant.proofing.update for settings, tenant.proofing.review for the review queue and decisions, tenant.proofing.records.read for records, tenant.proofing.records.revoke for revoking, and tenant.proofing.recovery.manage for opening, listing and cancelling recovery requests. Tenant Admin holds all six. Settings changes, reads of the queue and records, decisions and revocations appear in Audit under User directory, naming the route, level and reason, never claim values. Applicants' starts, results, letters and cancellations appear under Protocol activity as account.proofing with a specific reason, such as liveness_failed or proofing_verified. On the recovery page they appear as account.recovery, naming the person as the subject only, since nobody signed in: recovery_code_accepted, recovery_code_incorrect, recovery_code_attempts, then the proofing reasons. Opening, cancelling and using a recovery request appear in Audit under User directory.

Each person may make 30 proofing attempts an hour (each start, submission, letter and code counts), and at most 200 applications may wait for a referee. Both appear under Usage and limits on the Overview page. A restore to an earlier time keeps records revoked since and keeps the stricter of the earlier and current proofing settings. The BTL organization does not offer simulated proofing, and its levels cannot require it, because a made-up document must never describe BTL staff.