ADVISOR EVIDENCE PORTFOLIO
Dr. Gail-Joon Ahn — Center for Cybersecurity & Trusted Foundations, ASU SCAI
EIP-191 wallet-signed consent · zero-custodial design · bilateral authentication research · documented threat model
Six-step authentication chain. No passwords, no email, no OAuth. The wallet signature IS the identity.
eth_requestAccounts — Browser prompts wallet connection via EIP-1193 (window.ethereum). User approves address disclosure.Nonce generation — Server generates cryptographically random nonce bound to wallet address. Prevents replay attacks.personal_sign — EIP-191 structured message signed by wallet private key. Message includes address, nonce, timestamp, and consent text. User reviews and approves in wallet UI.ethers.verifyMessage — Server recovers signer address from signature. If recovered address matches claimed address, identity is cryptographically proven.JWT issuance — HS256 JSON Web Token issued with 15-minute TTL. Contains wallet address and role (Guide or Participant). Set as a client-set cookie (SameSite=Lax; not HttpOnly).jose.jwtVerify — Middleware validates JWT on every protected route. Expired or tampered tokens are rejected. No session database — stateless verification.Browser-extension wallets connect with zero SDKs or relays (EIP-6963, window.ethereum). An optional WalletConnect v2 path (Reown AppKit) is offered for mobile/multi-device access; it routes encrypted messages through the WalletConnect relay, which cannot read session material. No Privy, no third-party key custody. Private keys never leave the user’s device on either path.
Privy holds key material; OAuth providers control identity revocation. FSL’s architecture trusts only the user’s wallet and the Ethereum protocol. The WalletConnect relay is an accepted operational dependency for mobile access — it transports encrypted messages but holds no keys and cannot read session content. The benefit is zero third-party key custody across all connection paths.
Sovereign Guide (practitioner) — initiates sessions, records attestations, manages participant relationships via SovereignSession contract.
Participant — controls own data, grants/revokes access, holds decryption keys for personal records.
Cookie: fsl_jwt · Algorithm: HS256 · Max-age: 900 (15 minutes) · SameSite: Lax · Path: /
JWT payload contains wallet address, role, and issuance timestamp. No PII stored in token. Stateless verification — no session table required.
15-minute TTL. Automatic expiration without server-side session invalidation. Forces re-authentication via wallet signature. No stale sessions possible beyond 15-minute window.
SovereignLedger and BenevolenceFund contracts include pause() capability. Owner can halt all contract operations in response to detected compromise. On-chain circuit breaker.
Key compromise recovery via transferOwnership(). If the deployer wallet is compromised, ownership migrates to a new address. Full administrative control transfer without contract redeployment.
Recovery bundle encrypted with AES-256. Content-addressed immutability combined with access-controlled decryption (only the passphrase holder can decrypt).
Pinned and retrievable via IPFS. No private keys or secrets in the bundle — those are held separately in hardware.
Objective: A single wallet-signed consent architecture that simultaneously solves security (zero-trust, no custodial intermediaries), privacy (zero PHI by design), clinical governance (bilateral session consent), and blockchain infrastructure (on-chain attestation + token economics) — unified by one cryptographic primitive. This is the core contribution under U.S. Provisional Patent 64/063,037 (single-signer EIP-191 consent, zero-PHI constraint, Sovereign Guide attestation; CIP planned October 2026) and 64/106,748 (bilateral consent protocol, filed July 2026). The consent primitive is your domain.
THE DOCTORAL CONTRIBUTION — THE ASK
The doctoral contribution: completing bilateral two-party wallet-signed consent with client-side session encryption. This is the central research problem, covered by a filed provisional patent (64/106,748, July 2026).
Each party (Participant and Sovereign Guide) produces two signatures — an EIP-191 over a plain-language consent document and an EIP-712 over a structured session attestation. The Guide’s EIP-712 embeds the Participant’s EIP-712, binding both into one enforceable consent state; the session key derives via HKDF from both parties’ EIP-712 signatures, so no single party — including FSL — can decrypt unilaterally. The on-chain contract engineering and key-derivation design are Dr. Bošković’s domain; the bilateral consent-primitive formalization is Dr. Ahn’s. Your advisement is the gate — without formal verification that the bilateral consent primitive satisfies verifiability, attributability, revocability, and portability, the architecture cannot be claimed as cryptographically sound for mainnet.
Why this is hard: EIP-191 is single-signer by design — no established pattern for cryptographically binding two independent wallet signatures into one mutually-authorized session-consent primitive. EIP-1271 validates contract-account signatures — wrong shape for two independent EOA signatures. Existing multi-sig wallets (Safe, etc.) solve treasury authorization, not bilateral session consent. The consent topology has no existing formalization.
What I need: Dr. Ahn’s authentication/authorization/access-control expertise (SEFCOM) to formalize the bilateral consent primitive so it is cryptographically sound and access-control-correct. The CLEARS framework’s collaboration-aware authorization model maps directly — bilateral consent is a two-party collaboration context with dynamic privilege expansion (consent grant) and contraction (revocation).
Single-party attestation is built and exercised: session completion → HNT mint → DB record → on-chain attestation via registerClaim on SovereignLedger. 7 sessions recorded, 3 with on-chain attestation hashes. Today’s attestation is deployer-signed (the server writes to the contract). The participant’s wallet address is recorded but not cryptographically verified on-chain via their own signature.
| Phase | Label | Status |
|---|---|---|
| 1 | Contract Deployment | Deployed |
| 2 | Bilateral Consent Capture | Scaffolded |
| 3 | EncryptHealth Integration | Specified |
| 4 | Session Attestation | Specified |
| 5 | Bilateral Consent with Client-Side Session Encryption | Not implemented |
SovereignSession source verification pending on Blockscout. Locked as CIP entry for October 2026 non-provisional patent filing (provisionals 64/063,037 + 64/106,748).
FSL is not a covered entity. No protected health information is written on-chain. On-chain attestations contain only wallet addresses, cryptographic hashes, and timestamps. The regulatory load of HIPAA and 42 CFR Part 2 is acknowledged — and the scope boundary is architectural, not compliance-driven.
By holding no PHI, FSL avoids the compliance burden while preserving the ability to operate in behavioral health contexts. Participants control their own records; FSL provides the sovereign infrastructure, not the data custody. This is a deliberate zero-trust design choice: if FSL never holds the data, FSL cannot leak the data.
Nath, Soneji, Baek, Rubio-Medrano, Ahn. “Towards Collaboration-Aware Resource Sharing in Research Computing Infrastructures.” CIC 2025: 43–53.
CLEARS formalizes collaboration context and uses it to drive dynamic access control — specifically Privilege Expansion (granting access as collaboration deepens) and Privilege Contraction (revoking access as collaboration ends or roles change). It introduces a Collaboration Network construct to model who has access to what, under what collaboration context, across a project lifecycle.
| CLEARS Construct | FSL Equivalent |
|---|---|
| Collaboration Network | Sovereign Guide / Participant bilateral relationship |
| Privilege Expansion | EIP-191 consent grant at session start — participant authorizes Sovereign Guide access |
| Privilege Contraction | Participant-initiated revocation — DEPLOYED. The participant revokes an active grant via EIP-191 revocation signature; Lighthouse ACL access is removed and a revocation leaf is added to the Merkle permission tree (provable via inclusion proof). Access is both session-scoped and explicitly revocable on the participant’s terms. |
| Dynamic lifecycle-aware authorization | Session-bound EIP-191 attestation — access is temporally scoped, not permanent |
CLEARS handles WHO can access WHAT under which collaboration context. It does not solve the encryption problem — it does not prevent the infrastructure operator from reading the data. Phase 5 extends the model by adding client-side session encryption so that no single party, including FSL, can decrypt alone. This encryption layer is the engineering contribution co-advised by Dr. Bošković (Blockchain Research Lab); the bilateral consent primitive that CLEARS formalizes is Dr. Ahn’s domain. Phase 5 is not implemented — it is the doctoral contribution.
Why This Matters to the Center for Cybersecurity & Trusted Foundations
Dr. Ahn’s research in zero-trust architecture and cybersecurity foundations is the formal theoretical foundation for this system. The consent architecture treats the wallet signature as the single source of identity truth, with EIP-191 providing non-repudiation without a certificate authority — a direct application of zero-trust principles to health data governance.
The bilateral consent primitive is the core doctoral contribution — formalizing how two independent wallet signatures bind into one enforceable consent state. Your lab’s work on collaboration-aware authorization (CLEARS) and privilege management provides the formal framework this primitive needs. The client-side session-encryption layer that sits on top of the consent primitive is co-advised by Dr. Bošković (Blockchain Research Lab). I am asking for your formalization of the consent primitive itself as co-advisor.
Known security gaps are catalogued in a private pre-mainnet checklist, not concealed. This is the posture of a system designed for security audit, not one hoping to avoid it.