Identity and verification

Why these are separate from the account

A member account, from the Members and accounts page, is deliberately thin: an id and a lifecycle, nothing about the person. The details a particular site needs vary enormously, so they live in their own modules that a site includes only if it needs them. MemberIdentity is where those details go, and MemberVerification is where the record of checking them goes. Keeping the two apart means the store of facts about a member is separate from the store of decisions about those facts.

What MemberIdentity holds

MemberIdentity owns the details, addresses and documents attached to a member. It gives each member an identity record and hangs three kinds of data off it: detail values such as a name or date of birth, addresses, and uploaded documents such as a passport or a driving licence. The document files themselves are kept in the storage layer; the module holds the reference and the metadata around it. Records are added rather than overwritten, so the history of what a member submitted is preserved and the latest entry of each kind is the current one.

A site declares the types it needs

The module does not fix the list of details or documents; a site registers the ones it wants through the module's configuration class. An application module declares the detail types and document types it collects (for example a first name and a passport), and only those then appear. This is the standard configuration-class pattern: MemberIdentityConfig is the surface a site uses to describe what identity data the site deals in, while the runtime class handles the storing and fetching. Because the types are declared, the admin screens and any verification step can list exactly the documents a site expects. See Config classes.

What MemberVerification holds

MemberVerification is a single, append-only log of verification decisions for the whole site. Rather than each module inventing a verified flag on its own table, any module records its checks in one place. A record names the module, the kind of verification, and which row it refers to, along with whether that row was marked verified and when. Because records are only ever added, the latest one for a given thing is its current status and the earlier ones are its history. To answer whether something is verified, the module reads back the most recent record for it.

Registering a verification kind

Just as identity types are declared, a module registers the kinds of verification it takes part in through MemberVerification's configuration class. Registering a kind ties together a module, a verification name and the table whose rows are being checked, so the shared log knows what each record points back to. A site can then ask, in bulk, which members or which rows are verified, without every module keeping its own parallel flag. This is what lets one screen show a member's overall verification status drawn from checks that several different modules recorded.

How a site uses the two together

The typical flow joins them: a member submits details or a document, which MemberIdentity stores; a reviewer or an automated step looks at it and records the outcome in MemberVerification; later the site reads that log to decide what the member is allowed to do. The admin submodules, MemberIdentityAdmin and MemberVerificationAdmin, add the operator screens for reviewing submissions and browsing the verification log, following the pattern in Building an admin system. Note that the two never join tables directly; the link is the module, name and row reference carried in each verification record, which is the no-cross-module-joins rule from the Database layer conventions at work.

Next: Member settings and folders.