The IDV Landscape
The lie should be expensive. The truth should not.
That is a design aim, and it needs testing. A system should make impersonation difficult without making legitimate people pay for every uncertainty in the evidence.
The useful question is what an attacker must reproduce: a code, a document, a face, a device key, a history, or approval of a particular action. These are different boundaries. Adding more checks only helps when the service understands which boundary each one protects.
This page compares those boundaries qualitatively. It does not assign market prices to bypasses or claim a measured cost advantage for Pulse.
Three decisions, three questions
- Identity proofing: what evidence establishes the claimed identity and its relationship to the applicant?
- Authentication: does the returning user control the means of access associated with the account?
- Action authorization: may this person perform this exact action, for this recipient, now?
A control can help with one question without settling the others. A valid sign-in does not, by itself, establish that the account was enrolled legitimately or that the next transfer was knowingly approved.
Codes and phishing resistance
An attacker may try to obtain a phone number, steal a code, or relay a genuine sign-in. Manually entered one-time codes can be relayed because their output is not bound to the legitimate authentication session.
Phishing-resistant authentication uses a binding to the intended service. It is an important access control. Enrollment, recovery, session handling, and authorization still need their own checks. Platform attestation alone is not a substitute for phishing-resistant authentication.
NIST’s authentication guidance explains the distinction between replay resistance and phishing resistance.
Fabricated identities and generated media
A synthetic identity can combine real and fictional information. An attacker may accumulate records around it over time. A real phone or a long history therefore cannot, by itself, establish that the claimed identity is legitimate.
Document and face checks face other threats, including stolen evidence, generated media, and injected input. Those threats justify stronger acquisition, validation, comparison, and fraud controls. They do not establish that every document-and-selfie product fails.
The Federal Reserve’s synthetic-identity overview describes the identity-construction problem. NIST’s proofing guidance addresses evidence validation, applicant verification, injection, and generated-media threats.
Cryptographic documents and device keys
Checking a passport chip’s data against a trusted issuer signature establishes the authenticity and integrity of that signed data. Supported active or chip authentication separately helps address cloning. The presenter’s relationship to the document remains a separate question, as does approval of the current action.
Similarly, a valid device signature establishes integrity under a signing key. The service must establish trust in that key, check the request binding and freshness, and decide what the signed evidence means.
ICAO’s ePassport validation explanation distinguishes the document checks. Pulse’s evidence-chain documentation explains its signed-history and checkpoint requirements.
History adds another requirement
A signed device history can give a service evidence between identity checks: recorded activity, order, corroborating observations, and visible gaps. It gives an attacker more relationships to confront when the service verifies them together.
The strength depends on the implementation and the decision policy. A history can be internally consistent while incomplete. Missing readings can reflect permissions, hardware, travel, or interrupted collection. A legitimate device can be misused or relayed. Those conditions belong in the test plan.
Continuity is useful when it connects evidence to the decision. A score or a growing ledger alone does not complete that connection.
What Pulse is testing
Pulse aims to connect identity evidence, signed device history, and approval bound to a specific request. Your service verifies the evidence and owns the access decision.
The iOS Identity SDK provides capture, storage, signing, and continuity for evaluation. Android currently provides native workflow simulations. User-held presentation, the verifier, and the federation adapter are planned components.
A useful evaluation tests both legitimate users and failure cases: wrong-device approval, replay, request changes, relayed approvals, missing history, and recovery. Measure the outcome and the user burden. An unsuccessful bypass attempt alone does not prove that a boundary cannot be crossed.
The challenge boundary
The Pulse Bond Challenge defines qualifying server-recorded outcomes in its governing rules. A browser indication alone is not the server’s decision. The brief describes the research questions; the rules define authorized scope, qualifying findings, and payouts.
Confirm the current authorized targets and conditions before testing. This landscape analysis does not expand the challenge scope or amend its terms.