Skip to content
Architecture

From phone evidence to your service

Follow evidence from the phone to your service’s decision. Issuance, user-held presentation, the verifier, and the optional federation adapter are planned integration components.

Between the checks

Pulse turns the interval into evidence.

Start with identity. Build a signed history on the phone. Connect each return to the events that came before.

Issuance, user-held presentation, the verifier, and the optional federation adapter are planned integration components.

Pulse turns the interval into evidence Authentication is verifying who is signing in. A session is one continuous visit to a site. The first identity check anchors a history on the phone. Event receipts bind their payload hash, previous Merkle root, new root and ledger position with a device signature. Later checks connect to this chain. Request-bound proof leaves the phone for the Kenshiki verifier deployed inside the relying party’s service. The planned verifier checks the proof and returns claims. An optional federation adapter can convert the result to OIDC or SAML. The relying party owns its access policy: Validate result, Link account, Authorize request. Your service validates the result and request binding, then applies its access rules. Your user’s phone Kenshiki Identity SDK · signed event history OBSERVED OBSERVED First check DAY 0 Return DAY X Return DAY Y Identity evidenceHolder verificationDevice-bound key ANCHORS IDENTITY EVENT 1 none → root 1 DEVICE SIGNED EVENT 2 root 1 → root 2 DEVICE SIGNED EVENT 3 root 2 → root 3 DEVICE SIGNED EVENT 4 root 3 → root 4 DEVICE SIGNED EVENT 5 root 4 → root 5 DEVICE SIGNED VERIFY HISTORYBIND THIS ACTIONVERIFY NEW EVENTSBIND THIS ACTION Each event extends the cryptographic history. Each root is a cryptographic commitment to the event history. Request-bound proof Your service · relying party Kenshiki verifier · optional federation adapter Verify evidence Return claims Optional adapter Checked claims / OIDC / SAML Your application & access policy Validate result Link account Authorize request Your service validates the result and request binding, then applies its access rules.

Your user’s phone

Kenshiki Identity SDK · signed event history

  1. DAY 0

    Anchor identity

    Bind identity evidence to its holder and a device-bound key.

  2. THE INTERVAL

    Link and sign each event

    Each receipt binds an event hash to the previous and new ledger roots, then signs that link with the device key.

  3. DAY X · DAY Y

    Check each return

    Verify the history through the latest signed event and bind the result to the current action.

Request-bound proof

Your service · relying party

Kenshiki verifier · optional federation adapter

  1. Verify evidence
  2. Return claims
  3. Optional adapter
Checked claims / OIDC / SAML

Your application & access policy

  1. Validate result
  2. Link account
  3. Authorize request

Your service validates the result and request binding, then applies its access rules.

Event hash + previous root + new root + ledger position, bound by a device signature.

In the planned exchange, issuer signatures bind proofing claims. Device signatures bind recorded events. Your service evaluates their provenance and freshness separately. It can consume checked claims directly; an OIDC or SAML adapter is optional.

A valid signature establishes integrity under its signing key. Your service must establish key trust, freshness, and the history it expects, including an independently retained checkpoint when checking for missing later events. An internally consistent history alone cannot establish completeness or identity.