internal · technical brief · for the uninitiated
No password. No email address. No phone number. Nothing on zikora's side that could be stolen and used to pretend to be a member. This is the brief for anyone on the team who needs to explain that, or defend it, in plain words: what happens instead, and the answers to the questions people ask once they notice. The last section says exactly what the build does today.
A passkey is a pair of keys made by your phone the moment you join a circle. They are mathematically linked: anything signed by one can be checked with the other, but you cannot work out the private key from the public one. The private key is created inside your phone's secure hardware and stays there. The public key is handed to zikora, where it is useless to an attacker: it can only check signatures, never make them.
This is the WebAuthn standard, the same mechanism Apple, Google and Microsoft use for passkeys. zikora did not invent the cryptography; it chose to build on nothing else.
Every time zikora needs proof it is you, it sends your phone a challenge: a random number that has never been used before and expires in minutes. Your phone asks for your thumb or face, then uses the private key to produce a signature over that exact challenge plus the site's name. The signature goes back to zikora.
zikora takes the public key it kept at enrollment and checks: does this signature match this challenge under this key? If yes, the only device that could have produced it is the one holding the matching private key. That is the whole proof. The signature is not a password in disguise: it is good for this one challenge only, and a recording of it is worthless a minute later.
sequenceDiagram
participant P as your phone
participant Z as zikora
Z->>P: challenge (fresh random bytes) + relying party id "zikora.io"
Note over P: browser checks the id matches the site it is on
Note over P: your thumb or face unlocks the private key
P->>Z: signature over (challenge, zikora.io, presence flag) + credential id
Note over Z: look up the public key by credential id
Note over Z: verify signature · origin · relying party · counter
Z-->>P: signed in (or refused)
Because the private key is born in the device and cannot be exported. It lives in the secure enclave or platform keystore, and the only thing software can ask of it is "sign this", and only after a gesture from the person holding the phone. There is no file to copy, no string to type elsewhere.
So "your login" is not a thing you know. It is a thing your phone can do, when you are there. zikora records that too: each signature carries a presence flag saying a human gesture happened, and zikora refuses an approval without it. A member of a circle verifies by presence only.
One honest caveat. Apple and Google can sync passkeys across the devices signed into the same account. Then "your device" means "your account's devices". zikora cannot see the difference, which is why the "enrolled on this device" note on the roster is the browser's own memory, not a server claim.
The relying party is the site that is relying on the proof. Its id is the site's domain: for zikora, zikora.io. When your phone makes the key pair, it stamps that id onto the passkey. From then on the browser enforces one rule: this passkey is only ever offered to a page served from zikora.io.
That rule is what kills phishing. A site at zik0ra.io or zikora-verify.com can copy every pixel of the real thing, but when it asks the browser for a signature, the browser finds no passkey for that domain and offers nothing. There is no password to mistype into the wrong box. zikora also checks the origin of every signature on its side, so a signature made for another site is refused even if it somehow arrived.
Your passkey is a discoverable credential: the phone stores it under the site's name, so when you reach the sign-in page the browser already knows which passkeys belong to zikora.io and offers them. You pick one and touch. The signature arrives carrying a credential id, a random label created at enrollment, and zikora looks up which member of which circle that label belongs to.
That is why there is no handle field on the door. A handle would be a hint for an attacker and a chore for you, and the credential already names you. An id zikora has never seen is refused before any signature work happens, so there is nothing to probe.
| kept | what it is | could it impersonate you? |
|---|---|---|
| handle | the name your circle calls you, like "Dad" | no, it's a label |
| credential id | a random tag your phone picked at enrollment | no, it's a lookup key |
| public key | verifies your signatures | no, it can't make one |
| sign counter | how many times the passkey has signed | no, and it catches clones |
| escrow public key | lets others seal things only you can open | no, it can only lock |
| absent | why it matters |
|---|---|
| password | nothing to leak, guess, reuse or reset |
| email or phone number | no recovery link to phish, no number to port |
| your private key | never left the phone; zikora could not sign as you under subpoena or breach |
| your fingerprint or face | the gesture unlocks the key on the phone; biometrics never travel |
"No accounts" means exactly this: the roster holds enough to recognise you and nothing that could become you. A copy of zikora's entire database gives an attacker a list of names and public keys, which is to say, nothing.
No. Each verification is a new random challenge, and the signature is bound to it. Replaying yesterday's signature against today's challenge fails the check. Challenges also expire after a couple of minutes, visibly, and an expired one is not a verdict either way: it is silence, and the real phone can still answer a fresh one.
The sign counter is a second tripwire. Every passkey signature carries a count that must only go up. If a cloned key ever signed while the original sat idle, the numbers would collide and zikora would refuse.
There is no reset email, because there is no email. The private key is gone with the phone, and that is the point: a lost device means a new key, never a recovered one. On a new phone you open a recovery, your circle vouches for you with their own passkeys, and the new phone makes a fresh pair. The circle sees the change. Anything sealed to the old key that you had not yet opened shreds itself, and the sender is told why and offered to seal it again.
No. This is the design commitment everything else sits under. A verification is a signature from a device at a human gesture; no server, zikora's included, holds anything that can produce one. zikora's servers relay challenges and record verdicts. They cannot manufacture them. If the company were compromised, the attacker could read the roster and could not pass as a single member of it.
The real one signs. The fake one stalls.
For the reader who will be asked "but what does the code actually do". Everything below is in the app and gated by a scenario.
revision 97bc8a5bcb20