IDV Liveness & Facial Verification
No code, proto, schema, or service for this exists anywhere in the codebase today. This page exists only to name the gap and the problem it would close — it is not a spec, has no phases, and should not be treated as a commitment or a timeline.
The problem this would close
Holder Claim Integrity already hardens the moment a holder claims a credential with a knowledge challenge — proving the claimant knows facts drawn from the document itself, on top of controlling the inbox the credential was addressed to. That closes “controls an inbox” but not “is the physically-present, live person the credential describes” — a knowledge challenge can be passed by anyone who has seen the document (a family member, a colleague, someone who intercepted a copy), not only its rightful holder.
Liveness + facial verification would add a stronger front-end to that same claim step: confirming, at the moment of claim, that a live human is present (not a photo, a video replay, or a synthetic feed) and that their face matches a reference image tied to the claimed identity.
Why it isn’t scoped further here
This is deliberately not an implementation spec. The prerequisite decision record is ADR-015: Holder IDV Liveness Privacy; it proposes privacy and architecture guardrails but is not approved and does not authorize vendor selection, procurement, or biometric processing. Open decisions requiring explicit owner approval:
- Biometric data is a different privacy category than anything else this platform handles today. Every existing personal-data flow is built around encrypted-at-rest identifiers and structured fields, not raw imagery of a person’s face — a facial-match flow needs its own retention/consent/deletion story.
- It would very likely require a third-party liveness/face-match vendor — a procurement and data-processing-agreement decision, not an architecture decision alone.
- It isn’t on the roadmap. The launch-blocking backlog is already fixed elsewhere; adding IDV liveness to it is a roadmap-owner decision.
Where this would slot in, if built
Conceptually, this would sit inside the claim flow — an additional, stronger challenge option alongside (not replacing) the knowledge challenge — rather than as a new pipeline stage. See Chain of Custody Overview for how the claim step fits into the larger provenance arc.
Next step, if this gets prioritized
Approve or revise ADR-015 with product, privacy/legal, security, procurement, operations, and accessibility owners. Only then write a phased implementation spec with API contracts, state transitions, retention periods, provider failure semantics, and tests. Do not implement from this placeholder or the proposed ADR alone.