Combine documents, eID, authoritative sources, biometrics and evidence.
Evidence acquisition → validation → holder binding → policy → decision → audit
Identity proofing establishes confidence that a claimed identity belongs to the person participating in a transaction. It is distinct from account/session authentication, 1:1 biometric verification, 1:N identification, and authorization to perform an action.
CheckID publishes only source-backed methods: CheckID subject/process contracts, document/eID evidence, authoritative-source data and biometrics when the selected process supports them. User-declared data must remain distinct from document-derived, chip-derived, authoritative-source-derived and system-derived results.
CheckID API contract V1.2.260123 defines `POST /v1/create/subject`, `POST /v1/create/process`, `PUT /v1/perform/process` and `GET /v1/get/process/detail`. Runtime behavior must be described from contract fields such as `process_status`, `process_type`, `perform_result` and returned identifiers; this site does not invent undocumented states.
Holder binding connects identity evidence to the person participating in the journey. For face-based flows, capture, quality, PAD and 1:1 comparison are separate technical steps. PAD evidence applies to presentation attacks within its evaluated scope and does not establish overall channel security.
Failure classes include invalid input, unreadable evidence, unavailable source, insufficient biometric quality, inconclusive PAD/match results, invalid process state and policy-driven need for more evidence. Fallback or step-up behavior is published only when a contract or policy source supports it.
For bank and government use, a proofing result should be traceable to the subject/process, method/source, result, time and policy context where those implementation fields exist. Operational logging is not represented as business evidence without an explicit mapping.
Identity proofing establishes confidence in a claimed identity; it is distinct from authentication, 1:N identification and authorization.
| Evidence class | Validation | Holder binding | Failure boundary |
|---|---|---|---|
| User-declared | Not automatically verified | Requires additional evidence | Missing/inconsistent |
| Document/chip-derived | Integrity/authenticity within supported method | May use portrait ↔ live biometric | Unreadable/invalid/unsupported |
| Authoritative-source | Source/service-specific | Does not by itself prove the current actor is the subject | Unavailable/authorization/consent issue |
| Biometric | Quality, matching and PAD are separate results | 1:1 when reference/probe are defined | Inconclusive/mismatch/capture failure |
The CheckID source exposes subject and process with process_type/purpose/result context. Public examples preserve exact identifiers and enums.
In a face journey, holder binding may include capture, quality, PAD/liveness when required, a reference portrait and 1:1 matching. Each stage has a distinct failure boundary.
Step-up requests additional evidence or assurance when current evidence is insufficient. Specific triggers are public only when a policy source defines them.
CheckID may return verification/process results defined by the API; the bank or agency retains the final business decision unless a contract explicitly says otherwise.
