A real person then. The same person now.
Pulse connects identity evidence, signed device history, and approval of a specific action. A document check starts the process. It does not finish it. A sign-in recognizes a key. The decision still needs the person behind it.
Three steps, one continuous proof.
-
Prove the start.
Check the identity, verify its holder, and bind that evidence to a key on the person's device.
-
Preserve continuity.
Build a signed history of the phone's activity between checks. Keep the evidence with its owner.
-
Prove the person now.
Your face or fingerprint authorizes the device key. Your service checks the signed approval against the identity and history.
Was a live, legitimate person behind this identity and device at the start?
Is the same person behind them now?
If a fabricated identity passes account opening, later sign-ins faithfully let the fiction back in. If a real key is stolen, shared, or coerced, possession alone cannot answer who is using it. A key returning is not a person returning.
The proof begins with a proofed person.
Pulse brings the identity evidence together: a passport chip checked against its issuer, a driver's licence checked against the issuing state's record, and a carrier check of the phone number. Match the person’s face to the document portrait. Bind those checks to the device key to anchor the history that follows. Later checks return to that anchor.
A life in motion, measured where it happens.
Motion, surroundings, interaction rhythm, and the places a phone returns to build a worldline — the coherent thread of one person, one device, moving through real places and time. Repeated visits and time spent there give that history depth. One copied location or replayed signal does not reproduce it.
The evidence is concrete: charging overnight, the first unlock, steps on a walk, a drive corroborated by a car connection. A gap stays a gap. An unavailable reading never becomes an invented event.
Pulse evaluates the readings on the phone. Device signatures bind recorded events into a history whose integrity can be checked. At the decision point, your service must check the identity binding, the continuity evidence, and approval of the specific request. Together they support the claim:
A live person is behind this identity and device, and it is the same person over time.
Two channels. One moment. Required to agree.
Capture, storage, signing, and continuity are available for SDK evaluation. The verifier and user-held presentation are planned components. The web and call flows below describe what your integration must enforce.
-
Scan the code.
Connect the enrolled phone to the request on the page.
-
Confirm on the phone.
Review the request and authorize with your face or fingerprint.
-
Bind the action.
Your service must check the signed proof for that request before allowing the action.
The phone and the page provide two views of the same moment. Pulse evaluates whether place, time, network context, and interaction agree. No single reading decides; a cellular phone and a Wi-Fi laptop need not share an address to belong together.
A relay puts the page in the attacker's world and the phone in yours. Divergences become specific risk signals, alongside the identity binding and the approval of the request.
The bond must last beyond sign-in. The phone maintains a live, signed channel to the page; the service must require that bond for protected actions and stop accepting them when it drops. A stolen cookie is not a substitute for the enrolled phone.
Bind the approval to the request. Check the live bond at the decision. Keep the signed receipt.
The person on the line, proven on the line.
A familiar voice is not enough to authorize a transfer. For a call integration, use the enrolled phone as a second channel: show who is asking, what they are asking for, and get the person's approval before information, money, or authority changes hands.
Show the institution’s signed instructions on that channel and verify their origin. Give the person the actual request to approve, not a caller’s version of it. Bind the approval to the call's request and retain a signed receipt.
The attack stops scaling.
Remote fraud scales by copying evidence, replaying keys, and exploiting the gaps between checks. Require the whole chain for a protected action: the enrolled person, their device, its history, and approval of the action now. The attacker has to confront that chain. The attack becomes a constrained physical operation instead of an unlimited digital one.
- Identity evidence anchors the history.
- Device signatures bind each recorded event to the chain.
- Your face or fingerprint authorizes use of the device-bound key.
- Keep disclosures scoped to the request; review the actual data each feature sends.
- A signed approval is bound to one specific action.
- You own the record. Kenshiki does not resell it.
Follow the proof across every boundary.
See how identity evidence, signed events, user custody, and request-bound proofs fit together — and which checks your service must perform.
Start with one decision that should require a real person.
An account opening. A payment. A high-risk sign-in. A call. Choose the decision, the evidence it needs, and what your service must do when that evidence is missing.
Capture, storage, signing, and continuity are available for SDK evaluation. The verifier, user-held presentation, and federation adapter shown in the architecture are planned additions. Agree the working integration and acceptance criteria before the pilot starts.
You can’t fake a life in motion.