ADR-015: Privacy and Processing Boundaries for Holder IDV
Decision owner: Product and privacy/legal owners.
This ADR records proposed privacy and system-boundary decisions for a possible liveness and facial-match step during holder credential claiming (see IDV Liveness & Facial Verification). It does not authorize implementation, vendor procurement, or production processing of biometric data — those require the approvals and evidence listed below.
Context
The holder-claim flow in Holder Claim Integrity combines account control, a document-derived knowledge challenge, and claim-integrity controls. These reduce identity fraud but do not establish that the claimant is the live person represented by the credential.
Liveness and face matching could add evidence to that decision, but introduce sensitive biometric processing and a third-party trust boundary. The platform must not treat biometric capture as an ordinary form field, retain biometric material as an audit convenience, or let a vendor response silently replace the existing claim checks.
Proposed decision
If approved, build this as an optional, purpose-limited identity check within the existing holder-claim workflow, subject to all of the following:
- Explicit and informed participation. Explain purpose, data categories, processor identity, retention, and the non-biometric alternative before capture; obtain affirmative, versioned consent for this check only, never bundled with general account/credential terms. Declining must not be treated as evidence of fraud.
- No biometric material in Attest ID persistence. No raw face images, video, liveness frames, government-ID images, face templates/embeddings, or reusable biometric identifiers in application databases, object storage, logs, traces, analytics, or the tamper-evident audit chain. Hashing biometric material is not a substitute for deletion.
- Ephemeral processor handling. The provider processes only the minimum capture required, must contractually prohibit secondary use/sale/model-training, and must document deletion of source captures and derived artifacts, including backups and subprocessors.
- Server-owned claim decision. Core Engine remains the owner of the claim workflow; provider credentials stay server-side; provider callbacks are authenticated, bound to one claim attempt, replay-protected, and idempotent. Client-supplied pass/fail values are never authoritative.
- An advisory signal, not a replacement for claim safeguards. A provider pass is one input to the existing claim policy — it never bypasses account ownership, claim holds, knowledge challenges, or audit requirements. Fail/ambiguous/timeout results lead to a bounded retry or human review with an accessible non-biometric route, never a silent hold-clear.
- Minimal decision record. The audit chain may record an opaque attempt reference, event time, consent-notice version, provider/model identifier, and a coarse outcome (pass/fail/review/ unavailable/withdrawn) — never raw scores, images, templates, or vendor payloads.
- No unconsented reference-image reuse. No automatic face extraction from a custodian’s scanned source document or another credential for matching, without a clear, separate consent for that exact comparison.
- Jurisdiction and accessibility gate. Launch only where counsel has approved lawful basis, consent wording, biometric classification, cross-border processing, and minor handling; provide an accessible alternative for anyone unable to complete the biometric flow.
Alternatives considered
| Option | Assessment |
|---|---|
| Build liveness/face matching in-house | Rejected — presentation-attack detection is a specialized security capability without a demonstrated need to own it. |
| Let a vendor own the entire claim decision | Rejected — would move claim policy outside Core Engine and weaken existing audit/hold controls. |
| Persist images/templates to support disputes or retries | Rejected — increases breach impact with no demonstrated necessity; retries start a new short-lived provider session instead. |
| Make biometric verification mandatory for every holder | Rejected pending evidence and approval — proposed as optional with a non-biometric alternative. |
| Do not pursue IDV | Valid and the safest default until the approval gates are met — the effective decision while this ADR is proposed. |
Architecture consequences
- Core Engine owns orchestration and maps provider responses into a small internal result contract; provider-specific payloads never leak into REST/gRPC contracts.
- A provider adapter behind a narrow interface in the existing claim workflow — a new microservice isn’t justified without a separately approved isolation requirement.
- A provider-neutral attempt state machine (pending/completed/failed/review/expired/withdrawn), idempotent and scoped to the authenticated claim attempt.
- Strict request/response size limits, timeouts, rate limits, callback signature/freshness checks, and secret rotation; malformed or unbound responses are treated as non-success.
- Claim rules stay deterministic and auditable — no LLM or opaque vendor score as the sole basis for assigning or reversing credential ownership.
Threats and required controls
| Threat | Minimum control |
|---|---|
| Forged or replayed provider callback | Verify signature and freshness; bind attempt/holder/purpose/nonce; reject replay; process idempotently |
| Browser claims success without a provider result | Only accept server-verified provider results |
| Provider outage or malformed response | Fail closed for automatic clearance; preserve the claim hold; offer the alternative/review path |
| Capture or result leaks through observability | Redaction by construction; body logging disabled for capture/provider routes |
| Cross-claim or cross-holder result reuse | Bind each attempt to the authenticated holder and credential server-side |
| Provider uses data beyond the check | DPA and technical configuration prohibit secondary use; verify retention/deletion before launch |
| Mistaken mismatch | Human review/redress, accessible alternative, bounded retries, no automatic fraud conclusion from a mismatch alone |
| Excessive probing or account enumeration | Rate-limit attempt creation and result polling; non-enumerating responses |
Approval gates before implementation
This stays Proposed until the responsible owners record decisions for: product scope and optionality, privacy/legal (lawful basis, minors, retention, cross-border transfer), security architecture (trust model, callback verification, incident response), procurement (provider shortlist and due diligence), operations (outage runbook, monitoring), and accessibility (tested non-biometric route). Once approved, this ADR is updated with named decisions and owners, then a phased implementation spec follows with API contracts, state transitions, and retention durations.
Rollback and consequences
The feature must be independently disableable without blocking ordinary holder claims or changing the existing knowledge-challenge and claim-hold protections. Disabling it expires open provider sessions and prevents new attempts; it never erases existing claim evidence or silently clears holds.
Until approval and a separate implementation spec exist, the benefit is deferred — the platform avoids biometric data flows, provider lock-in, and new legal obligations prematurely.