Categories and Types

Verification is organised as three categories, with types built on top of them.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

The three categories

Identity — this person is who they say they are, usually via a government-issued document.
Age — this person is over a required age.
Affiliation — this person belongs to a group: a student, a nurse, a teacher, a serving member of the armed forces.

Why the distinction matters

They differ enormously in intrusiveness and in cost. An identity check involves a document and a photograph; an affiliation check can often be satisfied by confirming an e-mail address at a known domain.

Reaching for identity verification when affiliation would answer the question is the commonest design mistake here. If what you need to know is "does this person work for the NHS", you do not need their passport.

The seven types that ship

General ID Check — identity, valid two years.
Age Check — age, valid two years.
Student — affiliation, valid one year, with academic domains pre-filled.
Healthcare Worker — affiliation, one year, with NHS domains pre-filled.
Teacher, Military / Veteran, First Responder — affiliation, one year.

All ship disabled. They are starting points to adapt rather than a fixed menu — you can change their rules or add your own.

What a type defines

A type ties together the category, which provider handles it, how long a result stays valid, whether re-verification is allowed, whether a human must review it, whether it gates sign-in, and which security group success awards.

So the category says what is being established and the type says how, for how long, and what happens next.

Validity differs by category for a reason

Identity and age ship at two years; affiliation at one. That reflects how the underlying fact changes — somebody's date of birth does not, but their employer does. A student who verified eighteen months ago may well have graduated.

Keep the list short

Enable the types you have a use for. A long list of verification options presented to a user is a decision you have handed them, and most of it will be irrelevant to what they were trying to do.

Worked example

A service needs to know that clinicians are genuine and that everybody is over 18. It enables Healthcare Worker — satisfied for most users by an NHS e-mail address — and Age Check. It does not enable identity verification, because knowing a user's legal name adds nothing to what the service does and would mean asking everybody for a passport.

Recommendations

Choose the least intrusive category that answers your question.
Adapt the shipped types rather than starting from nothing.
Enable only what you use.
Set validity to how fast the fact changes, not to a round number.