Architecture Guide

This document describes the internal architecture of the BIA (Biological Identity Attestation) protocol, covering data flows from raw biometric ingestion through to OIDC token issuance and on-chain verification.

System Overview

The BIA platform consists of six major subsystems that work together to transform biological signals into cryptographically-verifiable identity claims.

BIA Platform Architecture

Client Applications

Web, Mobile, Healthcare

OIDC / REST API

BIA OIDC Provider

Authorization, Token, UserInfo endpoints

Biometric Pipeline

Face, fingerprint, EEG

Capture

Genomic Pipeline

VCF markers, HLA

Parse

ZK Prover

Circom / Groth16

Prove

Liveness Engine

Active liveness check

Verify

Developer Platform

Apps, SDK, Stats

Build

Template Store

Encrypted biometric templates

Chain (L2)

Commitments & proofs

Biometric Blob Store

Encrypted raw captures

Six subsystems transform biological signals into cryptographically-verifiable identity claims

Component Summary

Component	Responsibility
BIA OIDC Provider	Standards-compliant OpenID Connect server extended with biological identity claims
Biometric Pipeline	Ingests face, fingerprint, and EEG signals; extracts templates; computes match scores
Genomic Pipeline	Parses VCF files, extracts identity-grade SNP markers, generates commitments
ZK Prover	Compiles Circom circuits, runs trusted setup, generates and verifies Groth16 proofs
Liveness Engine	Active liveness detection to prevent replay and presentation attacks
Developer Platform	App registration, SDK configuration, test flows, and usage analytics
Template Store	Encrypted biometric template storage (AES-256-GCM, user-held keys)
Chain (L2)	Layer 2 for commitment anchoring, proof verification, and identity revocation
Encrypted Blob Store	Raw biometric data stored encrypted-at-rest, accessed only during re-verification

Data Flow: Registration

The registration flow transforms raw biological data into a cryptographic identity commitment.

Registration Flow

Capture & Process

User DeviceCapture face + fingerprint + EEG

Liveness EngineActive liveness check

UserUpload VCF file

Genomic PipelineParse VCF, extract 44 SNP markers

Biometric PipelineExtract & encrypt biometric templates

Prove & Anchor

ZK ProverReceive template hashes + genomic hash

ZK ProverGenerate identity commitment

ZK ProverCreate Groth16 proof

Chain (L2)Submit commitment + proof on-chain

Chain (L2)Verify proof, anchor commitment

CompleteRegistration complete — user receives commitment ID

Raw biometric data → ZK proof → on-chain commitment

Step-by-Step Breakdown

Biometric capture -- The user's device captures face imagery, fingerprint scans, and EEG signals simultaneously. The liveness engine validates these are from a live person in real time.
VCF upload -- The user uploads a VCF (Variant Call Format) file from a genomic sequencing provider. The genomic pipeline extracts 44 identity-grade SNP markers from autosomal chromosomes.
Template extraction -- The biometric pipeline converts raw signals into compact mathematical templates (512-dimensional face embeddings, minutiae maps, EEG spectral features).
Commitment generation -- The ZK prover takes hashes of all templates plus the genomic hash and produces a single identity commitment -- a binding, hiding cryptographic value.
Proof generation -- A Groth16 zero-knowledge proof is generated proving the commitment was correctly computed from valid biometric inputs, without revealing those inputs.
On-chain anchoring -- The commitment and proof are submitted to the Layer 2 chain. The verifier contract checks the proof and records the commitment with a block timestamp.

Liveness Pipeline

The liveness engine prevents presentation attacks (photos, videos, masks, synthetic biometrics) through multi-modal active challenges.

Liveness Verification Flow

Raw Capture

→

Quality Check

→

Active Challenge

→

Anti-Spoofing

→

Liveness Attestation

Face

Challenge: Random head pose (look left, up, blink)

Detects: Photos, flat masks, screen replays

Fingerprint

Challenge: Pressure variation (press hard, light, release)

Detects: Silicone molds, printed prints

EEG

Challenge: Cognitive task (mental arithmetic, oddball)

Detects: Pre-recorded EEG, signal injection

Signed attestation includes modalities checked, challenge IDs, device fingerprint, confidence score, and HSM signature.

Multi-modal active liveness prevents presentation attacks

Active Challenge Types

Modality	Challenge	What It Detects
Face	Random head pose sequence (look left, up, blink)	Photos, flat masks, screen replays
Fingerprint	Pressure variation pattern (press hard, light, release)	Silicone molds, printed fingerprints
EEG	Cognitive task (mental arithmetic, visual oddball)	Pre-recorded EEG, signal injection

Liveness Attestation

When liveness passes, the engine produces a signed attestation:

{
  "attestation_type": "active_liveness",
  "modalities_checked": ["face", "fingerprint", "eeg"],
  "challenge_ids": ["ch_face_a1b2", "ch_fp_c3d4", "ch_eeg_e5f6"],
  "timestamp": "2026-04-02T10:06:30Z",
  "device_fingerprint": "dev_9x8y7z",
  "confidence": 0.998,
  "signature": "MEUCIQDk..."
}

This attestation is bound to the OIDC session and surfaces as bio_liveness_active: true in the id_token.

EEG Neural Fingerprint

The EEG neural fingerprint is BIA's highest-uniqueness biometric modality. It extracts a 15-feature identity vector from brain electrical activity that is stable over time yet unique to each individual.

15-Feature Model

The neural fingerprint extracts features across five frequency bands from three cortical regions:

Feature Index	Frequency Band	Cortical Region	Feature Type
1--3	Delta (0.5--4 Hz)	Frontal, Central, Parietal	Spectral power ratio
4--6	Theta (4--8 Hz)	Frontal, Central, Parietal	Phase coherence
7--9	Alpha (8--13 Hz)	Frontal, Central, Occipital	Peak frequency + asymmetry
10--12	Beta (13--30 Hz)	Frontal, Central, Temporal	Event-related desynchronization
13--15	Gamma (30--100 Hz)	Frontal, Parietal, Temporal	Cross-frequency coupling

Device Compatibility

Device Type	Channels	Sampling Rate	BIA Compatible	Notes
Clinical-grade (BrainVision, g.tec)	32--256	500--2000 Hz	Yes	Full 15-feature extraction
Consumer-grade (Muse 2, Emotiv Insight)	4--14	256 Hz	Yes	12/15 features extractable
Single-channel (NeuroSky)	1	512 Hz	Partial	6/15 features, reduced confidence
Ear-EEG (cEEGrid, IDUN)	6--10	250--500 Hz	Yes	10/15 features extractable

Minimum requirements

BIA requires at least 8 of 15 features for neural fingerprint authentication. This means a minimum of 4 EEG channels at 250 Hz or higher sampling rate.

Cognitive State Mapping to Health Vectors

During the neural fingerprint capture, the EEG data also yields five real-time health vectors derived from cognitive state analysis:

flowchart TD
    EEG[Raw EEG Signal\n15 Features Extracted] --> ID[Identity Vector\n15-dim]
    EEG --> HV[Health Vector Extraction]

    HV --> CL[Cognitive Load\nTheta/Alpha Ratio\nFrontal Region]
    HV --> SI[Stress Index\nBeta Asymmetry\nFrontal-Temporal]
    HV --> SQ[Sleep Quality\nDelta Power\nGlobal Distribution]
    HV --> FS[Focus Stability\nAlpha Suppression\nParietal-Occipital]
    HV --> EV[Emotional Valence\nFrontal Asymmetry\nAlpha Band]

    CL --> HVO[health_vectors Object\nin id_token]
    SI --> HVO
    SQ --> HVO
    FS --> HVO
    EV --> HVO

Health Vector	Derivation	Values	Clinical Relevance
`cognitive_load`	Theta/Alpha ratio at frontal electrodes	`low`, `normal`, `high`, `overload`	Cognitive impairment screening
`stress_index`	Beta asymmetry across frontal-temporal regions	`low`, `moderate`, `high`, `acute`	Stress-related condition monitoring
`sleep_quality`	Delta power distribution and spindle detection	`poor`, `fair`, `good`, `excellent`	Sleep disorder assessment
`focus_stability`	Alpha suppression at parietal-occipital sites	`unstable`, `moderate`, `high`, `exceptional`	ADHD screening, cognitive fitness
`emotional_valence`	Frontal alpha asymmetry (Davidson model)	`negative`, `neutral`, `positive`, `elevated`	Mental health baseline tracking

Health vectors require explicit consent

Health vectors are only included in the id_token when the bio:neuro scope is requested AND the user explicitly consents to cognitive state sharing during the authorization flow.

ZK Proof Pipeline

BIA uses zero-knowledge proofs to allow users to prove biological identity properties without revealing the underlying biometric data.

Pipeline Stages

flowchart LR
    A[Circom Circuit\nDefinition] --> B[Circuit\nCompilation]
    B --> C[Trusted Setup\nCeremony]
    C --> D[Proving Key\n+ Verification Key]
    D --> E[Proof Generation\nClient-Side]
    E --> F[Proof Verification\nOn-Chain]

1. Circuit Compilation

BIA circuits are written in Circom 2.0 and compiled to R1CS (Rank-1 Constraint System):

Circuit	Constraints	Purpose
`bia-identity-v2`	~2.1M	Full identity commitment (all modalities)
`bia-genomic-commitment-v2`	~850K	Genomic marker commitment only
`bia-liveness-attestation-v1`	~320K	Liveness attestation verification
`bia-neuro-match-v1`	~1.4M	Neural fingerprint matching
`bia-selective-disclosure-v1`	~450K	Selective claim disclosure

2. Trusted Setup

BIA uses a Groth16 proving system which requires a circuit-specific trusted setup ceremony:

Phase 1 (Powers of Tau): Shared across all circuits. BIA uses the Hermez ceremony with 54 participants.
Phase 2 (Circuit-specific): Conducted per circuit with a minimum of 10 independent participants. Ceremony transcripts are published and verifiable.

3. Proof Generation

Proof generation runs on the user's device (browser via WASM or native mobile):

Circuit	Proof Time (Mobile)	Proof Time (Desktop)	Proof Size
`bia-identity-v2`	~12s	~4s	256 bytes
`bia-genomic-commitment-v2`	~5s	~1.8s	256 bytes
`bia-liveness-attestation-v1`	~2s	~0.7s	256 bytes
`bia-neuro-match-v1`	~8s	~2.5s	256 bytes
`bia-selective-disclosure-v1`	~3s	~1s	256 bytes

Proof generation is always client-side

Biometric data never leaves the user's device. The ZK prover runs locally and only the proof (256 bytes) and public inputs are transmitted.

4. Proof Verification

Verification happens both on-chain and off-chain:

On-chain: The L2 verifier contract checks the proof against the verification key. Gas cost is ~230K gas per verification.
Off-chain (OIDC mode): The BIA OIDC Provider verifies the proof server-side during the token exchange. This adds ~50ms to the token endpoint response time.

OIDC Authentication Flow

The complete authentication flow from the relying party's perspective:

sequenceDiagram
    participant RP as Relying Party
    participant UA as User Agent
    participant BIA as BIA OIDC Provider
    participant LE as Liveness Engine
    participant BP as Biometric Pipeline
    participant ZK as ZK Prover

    RP->>UA: Redirect to /bio-oidc/authorize
    UA->>BIA: GET /bio-oidc/authorize?...
    BIA->>UA: Display biometric verification UI

    UA->>LE: Begin biometric capture
    LE->>LE: Active liveness challenge
    LE-->>BP: Verified live capture

    BP->>BP: Extract templates
    BP->>BP: Match against stored templates
    BP-->>UA: Match result + confidence

    UA->>ZK: Generate identity proof (client-side)
    ZK-->>UA: Groth16 proof (256 bytes)

    UA->>BIA: Submit proof + biometric attestation
    BIA->>BIA: Verify proof
    BIA->>BIA: Compute bio claims
    BIA->>UA: Redirect to redirect_uri?code=...

    UA->>RP: GET /callback?code=...&state=...
    RP->>BIA: POST /bio-oidc/token (exchange code)
    BIA-->>RP: id_token + access_token

    RP->>RP: Validate id_token signature
    RP->>RP: Read bio claims
    RP->>RP: Make authorization decision

Timing Budget

Phase	Duration	Notes
Biometric capture	3--8s	Depends on modalities and challenge complexity
Template extraction	200--500ms	Runs on-device
Liveness analysis	500ms--1s	Server-side analysis of challenge responses
ZK proof generation	1--12s	Depends on circuit and device capability
Token exchange	50--100ms	Includes server-side proof verification
Total (typical)	5--15s	End-to-end from start of capture to id_token

On-Chain vs OIDC Mode

BIA supports two verification modes. You can use both simultaneously for different parts of your application.

Aspect	OIDC Mode	On-Chain Mode
Identity assertion	`id_token` JWT signed by BIA	Commitment on L2 chain
Verification	JWT signature check	Smart contract verification
Latency	50--100ms	2--15s (block confirmation)
Cost	API usage fee	Gas cost (~230K gas per verification)
Privacy	BIA sees bio claims, RP sees claims	Nobody sees biometric data; only commitments
Offline verification	No (needs BIA server)	Yes (only needs chain access)
Revocation	Token expiry + revocation endpoint	On-chain revocation registry
Best for	Web apps, healthcare portals, quick integrations	DeFi, DAOs, privacy-critical applications
Decentralization	Semi-centralized (BIA OIDC Provider)	Fully decentralized (chain + client)

Decision Guide

flowchart TD
    A[Start] --> B{Need decentralized\nverification?}
    B -->|Yes| C{Acceptable gas\ncosts?}
    B -->|No| D[Use OIDC Mode]
    C -->|Yes| E[Use On-Chain Mode]
    C -->|No| F{Can tolerate\nhigher latency?}
    F -->|Yes| G[Use On-Chain Mode\nwith batched proofs]
    F -->|No| D
    D --> H{Also need\non-chain anchoring?}
    H -->|Yes| I[Use Hybrid:\nOIDC + Commitment]
    H -->|No| J[OIDC Only]

Security Model

Trust Boundaries

+------------------------------------------------------------------+
|                    UNTRUSTED: User Device                         |
|  +------------------------------------------------------------+  |
|  | Biometric sensors, EEG device, browser/app environment      |  |
|  | ZK proof generation runs here (biometrics never leave)      |  |
|  +------------------------------------------------------------+  |
+------------------------------------------------------------------+
                              |
                    Proof + Attestation (no raw biometrics)
                              |
+------------------------------------------------------------------+
|                    SEMI-TRUSTED: BIA OIDC Provider               |
|  +------------------------------------------------------------+  |
|  | Verifies proofs, issues tokens, manages sessions            |  |
|  | Sees: bio claims, assurance level, proof validity           |  |
|  | Does NOT see: raw biometrics, genomic data, EEG signals     |  |
|  +------------------------------------------------------------+  |
+------------------------------------------------------------------+
                              |
                         id_token (signed)
                              |
+------------------------------------------------------------------+
|                    UNTRUSTED: Relying Party                       |
|  +------------------------------------------------------------+  |
|  | Verifies JWT signature, reads bio claims                    |  |
|  | Sees: bio_assurance_level, amr, liveness status             |  |
|  | Does NOT see: biometric templates, match scores, raw data   |  |
|  +------------------------------------------------------------+  |
+------------------------------------------------------------------+

Encryption Layers

Layer	Algorithm	Key Management	Protects
Transport	TLS 1.3 (ECDHE + AES-256-GCM)	Automated via ACME	All data in transit
Template storage	AES-256-GCM	User-derived key (HKDF from biometric + passphrase)	Stored biometric templates
Commitment	Pedersen commitment (BN254 curve)	No key -- computationally hiding	Biometric-to-identity binding
Blob storage	AES-256-GCM + envelope encryption	KMS-managed DEK/KEK hierarchy	Raw biometric captures
Token signing	ECDSA P-256 (ES256)	HSM-backed, rotated quarterly	JWT integrity and authenticity

Key Hierarchy

Root Key (HSM, never exported)
  |
  +-- Token Signing Key (ES256, rotated quarterly)
  |     |
  |     +-- id_token signatures
  |     +-- access_token signatures
  |
  +-- Attestation Signing Key (ES256, rotated monthly)
  |     |
  |     +-- Liveness attestation signatures
  |     +-- Biometric match attestations
  |
  +-- KEK (Key Encryption Key, AES-256)
        |
        +-- DEK per user (Data Encryption Key, AES-256-GCM)
              |
              +-- Biometric template encryption
              +-- Blob storage encryption

Scaling Considerations

Proof Generation Performance

Client-side proof generation is the primary bottleneck. Performance varies by device:

Device Category	Example	`bia-identity-v2` (2.1M constraints)	Viable?
Flagship phone (2025+)	iPhone 16 Pro, Pixel 9 Pro	~8s	Yes
Mid-range phone	Pixel 8a, Galaxy A55	~15s	Marginal
Desktop (modern)	M3 MacBook, Ryzen 7	~4s	Yes
Desktop (budget)	Intel i3-12100	~8s	Yes
Browser (WASM)	Chrome on flagship phone	~12s	Yes
Browser (WASM)	Chrome on mid-range phone	~22s	Marginal

Reducing proof time

For latency-sensitive applications, request only the modalities you need. bia-genomic-commitment-v2 (850K constraints) takes 3x less time than the full identity circuit.

Circuit Sizes and Artifacts

Artifact	`bia-identity-v2`	`bia-genomic-commitment-v2`	`bia-liveness-attestation-v1`
R1CS file	48 MB	19 MB	7 MB
Proving key	72 MB	28 MB	11 MB
Verification key	1.2 KB	1.2 KB	1.2 KB
WASM witness generator	12 MB	5 MB	2 MB
Proof output	256 bytes	256 bytes	256 bytes

Proving keys are downloaded once and cached on-device. The WASM witness generator loads into browser memory during proof generation.

Gas Costs (L2)

Operation	Gas (Optimistic L2)	Approx. Cost at 0.01 gwei
Commitment registration	~350K	~$0.002
Proof verification	~230K	~$0.001
Identity revocation	~80K	~$0.0005
Batch verification (10 proofs)	~1.2M	~$0.007

Integration Patterns

Healthcare Applications

Use case: Patient identity verification for telehealth, prescription management, and clinical record access.

flowchart LR
    P[Patient] --> BIA[BIA OIDC\nSubstantial Assurance]
    BIA --> EHR[EHR System]
    BIA --> TP[Telehealth\nPlatform]
    BIA --> RX[e-Prescribing]

    EHR --> |bio_assurance: substantial| AC1[Read medical\nrecords]
    TP --> |bio_liveness: true| AC2[Start video\nconsult]
    RX --> |bio_assurance: high\namr includes bio:face| AC3[Authorize\ncontrolled substance]

Recommended configuration:

Minimum assurance: substantial
Required modalities: face + fingerprint
Liveness: Required for every session
Scopes: openid bio bio:liveness

Clinical Trials

Use case: Participant identity verification, duplicate enrollment prevention, and consent verification.

Recommended configuration:

Minimum assurance: high
Required modalities: face + fingerprint + genomic commitment
Scopes: openid bio bio:liveness bio:genomic
Use bio_commitment_hash to detect duplicate enrollments across trial sites without sharing PII

Insurance

Use case: Policyholder verification for claims processing, fraud prevention, and remote identity proofing.

Recommended configuration:

Minimum assurance: substantial for routine claims, high for high-value claims
Required modalities: face (minimum); add fingerprint for claims above threshold
Scopes: openid bio bio:liveness
Use bio_match_score for step-up verification decisions

Identity Verification (KYC/AML)

Use case: Regulatory identity proofing where biometric binding to a real person is required.

Recommended configuration:

Minimum assurance: high
Required modalities: All available (face, fingerprint, eeg)
Scopes: openid bio bio:liveness bio:neuro bio:genomic
Use on-chain mode for audit trail immutability
Use zk_proof_id for regulatory audit references

Architecture Guide

System Overview​

Component Summary​

Data Flow: Registration​

Step-by-Step Breakdown​

Liveness Pipeline​

Active Challenge Types​

Liveness Attestation​

EEG Neural Fingerprint​

15-Feature Model​

Device Compatibility​

Cognitive State Mapping to Health Vectors​

ZK Proof Pipeline​

Pipeline Stages​

1. Circuit Compilation​

2. Trusted Setup​

3. Proof Generation​

4. Proof Verification​

OIDC Authentication Flow​

Timing Budget​

On-Chain vs OIDC Mode​

Decision Guide​

Security Model​

Trust Boundaries​

Encryption Layers​

Key Hierarchy​

Scaling Considerations​

Proof Generation Performance​

Circuit Sizes and Artifacts​

Gas Costs (L2)​

Integration Patterns​

Healthcare Applications​

Clinical Trials​

Insurance​

Identity Verification (KYC/AML)​

Further Reading​

System Overview

Component Summary

Data Flow: Registration

Step-by-Step Breakdown

Liveness Pipeline

Active Challenge Types

Liveness Attestation

EEG Neural Fingerprint

15-Feature Model

Device Compatibility

Cognitive State Mapping to Health Vectors

ZK Proof Pipeline

Pipeline Stages

1. Circuit Compilation

2. Trusted Setup

3. Proof Generation

4. Proof Verification

OIDC Authentication Flow

Timing Budget

On-Chain vs OIDC Mode

Decision Guide

Security Model

Trust Boundaries

Encryption Layers

Key Hierarchy

Scaling Considerations

Proof Generation Performance

Circuit Sizes and Artifacts

Gas Costs (L2)

Integration Patterns

Healthcare Applications

Clinical Trials

Insurance

Identity Verification (KYC/AML)

Further Reading