Documentation  /  Owner identity & proof-of-personhood

HiNet — Owner Identity & Proof-of-Personhood

Status: [NEW spec] · owner-binding is [MVP-buildable], personhood is [LATER / partly-research]. Reuses Quorumz wallet.ts identity core; feeds Routing §2.5 personhood gate + Identity §7.1 per-owner caps; sits above the Ed25519 node identity (app/osx/hinetd/hinetd/node_identity.py).

This spec answers "a private key always attributable to the same human owner, gated by a face/fingerprint." It keeps two goals strictly separate, because they are at very different maturity levels and conflating them is the trap:

• (A) Owner-binding — is this the same human who set up this identity? A 1:1, on-device check. Buildable today, fully sovereign (biometric template never leaves the device).
• (B) Proof-of-personhood — is this a different human from every other node's owner (one-human-one-iCore)? A 1:N check against the whole population. Cannot be done locally — it inherently needs a shared reference — so it imports external trust and is deferred.

The single fact that makes (A) easy and (B) hard: you cannot derive a stable key from a biometric (biometrics are fuzzy — every capture differs). So the key is random and biometric-unlocked, never computed from* a face; and uniqueness needs something to compare against.

1. The two-key model [MVP]

HiNet separates the human from the device:

Owner certifies node. On node creation the owner key signs the node's Ed25519 pubkey → an OwnerBinding{ owner_pubkey, node_id, sig, issued_at }. This binds a node to a human without merging the two keys. One human may own several nodes (all owner-certified) — which is why Sybil defense is per-owner (§4), not per-node.

Why two keys, not one: the node key must be device-local and cheap to use for every receipt/commit; the owner key must survive device loss and carry the (scarce, expensive) personhood credential. Different lifetimes, different custody.

2. Owner-binding — biometric-gated key [MVP, buildable now]

2.1 Reuse the Quorumz identity core

Quorumz already ships the exact primitive (apps/web/src/app/contribute/wallet.ts, dependency-light — only ethers): WebAuthn PRF extension as a client-side KDF → a 32-byte secret → AES-256-GCM decrypts a locally-generated key → the key's address is the stable, PII-free identity; server trust is pure ECDSA-signature verification (eth_account), no server-side WebAuthn. Recovery via alias → server ciphertext bundle → (passkey-PRF | recovery code | passphrase) → same seed → same key gives the cross-device portability a raw Secure-Enclave key cannot. HiNet reuses this near-verbatim as the owner-key custody + owner-signature substrate (custody schema user_accounts; signed-write store-keys; verify verify_evm_signature).

The clever part we keep: the passkey is not the identity key — it is the biometric-gated KDF that unlocks a portable identity key. That is what lets the same human recover the same owner key on a new device.

2.2 The biometric gate (what "face/fingerprint" actually is)

• Apple (native path): the passkey/authenticator key lives in the Secure Enclave; a SecAccessControl with .biometryCurrentSet + .privateKeyUsage forces Face ID / Touch ID on every use and invalidates the key if the enrolled biometric set changes. The biometric template is created, encrypted, and stored only in the Secure Enclave — never sent to Apple, never in backups, never given to the app (the app gets only success/failure). This satisfies "templates never leave the device" in hardware.
• Cross-platform: a WebAuthn/FIDO2 platform authenticator (passkey) is the same non-exportable-key-gated-by-biometric model. The node-identity abstraction treats an SE key and a passkey as interchangeable backends.
• No separate face/fingerprint library at MVP. The platform biometric (via the passkey) is the gate. Apple's Vision does face detection, not identification; MediaPipe FaceMesh is geometry, not recognition; a standalone fingerprint matcher (SourceAFIS/NBIS) isn't needed (most laptops lack readers; WebAuthn already wraps Touch ID) and would make us a raw-biometric custodian. Do not attempt fuzzy-extractor key derivation from a face (research-grade; faces are low-entropy; helper-data leaks).

2.3 Harden beyond Quorumz (required for "always attributable")

Quorumz deliberately weakened two things for reach; HiNet must re-tighten them so the key is biometric-exclusive, not merely biometric-gated: 1. userVerification: "required" (Quorumz uses "preferred" to dodge an iOS 26.2 WKWebView bug) — with real-device testing per the Quorumz passkey spec. 2. Lock the non-biometric recovery paths. Quorumz's passphrase + recovery-code paths reconstruct the same key with no biometric. HiNet either removes them or binds recovery behind the personhood credential (§3) — otherwise "attributable to the same human" is only as strong as a written-down code.

2.4 The honest limit (state it plainly)

Owner-binding is device-scoped, not human-scoped: it proves "the enrolled owner of this device." "Always the same human" holds as long as enrollment is controlled and the device (or a recovered owner key) persists. Moving to a new device is an explicit key-rotation / re-attestation ceremony (the Quorumz recovery-custody path is one; a fresh node key + owner re-cert is another) — not something the enclave gives for free.

3. Proof-of-personhood — external credential, never biometrics-in-HiNet [LATER / RESEARCH]

Global one-human-one-iCore cannot be guaranteed while keeping everything local — two isolated nodes literally cannot prove they aren't the same human without comparing against something shared. So HiNet does not put biometrics into the network. Instead the owner attaches an external personhood credential to the owner key, carried as a ZK verifiable credential (Privado / Polygon-ID style) so HiNet verifies "unique human" without seeing any biometric or the underlying account:

The Routing §2.5.2 personhood field records which credential is verified on the owner key. proof_of_personhood = a verified external credential; account = mere owner-gating (farmable); none = nothing.

Research track (only if HiNet must be self-contained): a HiNet-native ZK/MPC biometric dedup among nodes — each iCore contributes a secret-shared embedding to an MPC set-membership check returning only a duplicate / not-duplicate bit. This is essentially rebuilding World's SMPC system and carries the same non-collusion assumptions → long-horizon, not MVP.

(Optional Phase-1 hardening, no biometrics: App Attest / DeviceCheck proves the node runs on a genuine, unmodified Apple device — raises the bar against cloned/emulated nodes without touching personhood.)*

4. How this closes the routing Sybil gate

This spec resolves open decision #1 of Routing §2.5 ("payout-bearing routing needs proof-of-personhood"): - Payout-bearing routing requires personhood = 'proof_of_personhood' (Identity §4.5.4) → a verified external PoP credential on the owner key. - Per-owner_ref speciality caps (Identity §7.1): every node the owner key certifies (§1) shares one cap, so a parallel Sybil farm — the same human minting N nodes — cannot multiply its payout-bearing specialities. Calendar-cost accumulation stays rate-limiting only; personhood + the per-owner cap are what actually bound Sybils. - Owner→node certification lets the network attribute all of a human's nodes to one owner_ref, even across devices.

5. Reuses vs adds

Reuses [EXISTS]: Quorumz wallet.ts (WebAuthn-PRF → AES → key custody, BIP39/HD, recovery), the user_accounts ciphertext-custody schema + signed-write store-keys + verify_evm_signature server trust, the anti-Sybil device/IP heuristics (weak second layer), the Quorumz iOS/WebAuthn config learnings; HiNet Ed25519 node identity (node_identity.py); Apple Secure Enclave + LocalAuthentication + WebAuthn platform APIs; Routing §2.5 personhood gate + Identity §7.1 per-owner caps. Adds [NEW]: the two-key owner↔node model + OwnerBinding certificate; biometric enforcement (userVerification: required + non-biometric-fallback lockdown); the external PoP credential integration as a ZK-VC on the owner key; the explicit device-vs-human scope boundary + cross-device rotation ceremony. Explicitly out: biometrics ever entering the HiNet network; fuzzy-extractor key derivation; a standalone fingerprint matcher; any claim of local one-human-one-node.

6. Open decisions [OPEN]

1. Owner-key curve — secp256k1/EVM (Quorumz-compatible, reuse wallet.ts + user_accounts verbatim) vs Ed25519 (consistent with the node key). Leaning secp256k1 for maximal reuse; the node key stays Ed25519.
2. Recovery lockdown — how hard to disable the non-biometric passphrase/recovery-code paths (biometric-exclusivity vs. the real risk of permanent key loss). Likely: keep an encrypted recovery but gate its use behind the personhood credential.
3. Where owner identity lives — reuse the Quorumz backend + user_accounts directly (shared identity across Quorumz + HiNet — attractive, given the map integration) vs. a dedicated HiNet identity service. Leaning: shared Quorumz backend, HiNet-namespaced.
4. First PoP provider(s) — World ID (strongest, imports Orb+MPC trust) vs. BrightID (no biometrics, weaker) vs. Passport (soft). Possibly accept several, weighted.
5. Cross-device portability model — server ciphertext custody (Quorumz-style, portable) vs. SE-only + re-attestation ceremony (stronger locality, worse UX). Leaning portable custody for owners, with the node key re-minted per device.
6. Enrollment liveness — do we add MediaPipe/local liveness to resist a photo spoof of the owner-binding step, or rely on the platform authenticator's own presence check? (MVP: rely on the platform.)

Next: Query classification & quorum cache →  ·  All documentation →