HAMSAIDArchitecture brief · for security and data-protection review
Identity that works because nobody holds the whole picture.
HamsaID proves a real person is present with one wave of the hand. No raw biometric store. No master seed. No global ID. This brief summarises what each layer of the system holds, what it never receives and what happens if one party is breached.
Four separated layers
01 · Sensor / terminal
Capture and transform
Holds briefly
Raw frames in volatile memory; untransformed embedding
Holds securely
Context transform key; terminal identity key
Never receives
User seed; civil identity; other contexts’ transform keys
02 · User phone
Root of authority
Holds
Private seed in secure storage; consent and context capsules; scoped pseudonym keys
Never receives
Raw biometric frames; resolution corpus; biometric transform keys
03 · Resolution core
Scoped matching
Current deployment
Attested enclave; encrypted at rest; per-context partitions
Raw or transformed biometric; private seed; global subject identifier
Biometric data lifecycle
The data path is deliberately one-way: raw NIR, RGB and depth frames are processed in volatile sensor memory, transformed for one context and overwritten before the next capture.
Never retainedRaw frames and untransformed feature vectors remain inside the sensor. No raw biometric exists at rest.
May be retainedTransformed, encrypted, context-bound templates. Never raw frames, the user seed, card PAN or a universal identifier.
What we cannot do
No database of raw palm captures to sell or hand over.
No master key that could impersonate every user.
No raw biometric capture ever reaches the resolution core.
No palm data and no global ID reach a relying party.
No permission survives revocation or expiry.
If one party is breached
A breach exposes protected data for the affected context only: not raw captures, not the user seed, not a card number (PAN), not a global identifier. Contexts remain separate by design, so one compromised deployment cannot be replayed against another.
Current deployment and target architecture
Current deployment: hardware isolation, encryption at rest and per-context partitions inside an attested confidential-computing enclave. Target architecture: distributed custody through secure multi-party computation across legally separate operators, so no matching operator holds a complete template.
Regulatory posture
Designed around data minimisation, explicit purpose and revocable consent (GDPR); user-controlled authority with selective, context-bound assertions (eIDAS 2.0); bounded use and auditable flows built to avoid indiscriminate identification (EU AI Act).
Regulatory alignment depends on the full deployment, operating context and customer configuration. This brief describes architectural design goals, not legal advice or a blanket certification. Technical, regulatory, deployment and partner claims require final approval before external distribution.