Architecture

From phone evidence to your service

Start with how each event extends the evidence chain, then follow the system flow below. The verifier and federation adapter shown 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.

The verifier and 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. It verifies the proof, applies policy, and passes an OIDC or SAML response to the RP’s existing sign-in system: Validate response, Establish session, Authorize request. The RP validates issuer, audience and request binding, then applies its own 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 & federation adapter Verify Apply policy OIDC / SAML 2.0 OIDC callback / SAML ACS Your existing authentication & authorization Validate response Establish session Authorize request The RP validates issuer, audience and request binding, then applies its own 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 & federation adapter

  1. Verify
  2. Apply policy
  3. OIDC / SAML 2.0
OIDC callback / SAML ACS

Your existing authentication & authorization

  1. Validate response
  2. Establish session
  3. Authorize request

The RP validates issuer, audience and request binding, then applies its own access rules.

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

Issuer signatures bind proofing claims. Device signatures bind subsequent events. Your service evaluates their provenance and freshness separately.

Next: custody and disclosure →