Thesis defense/viva prep: 13 jury Q&A + demo list + lead points (Sonnet review)

[ahmetabdullahgultekin]

Defense/viva Q&A pack (Sonnet review, 2026-06-13). Tone: honest + precise, not apologetic. Name each gap before the juror does.

13 toughest questions + honest answers (condensed)

1. §6.5 border-control / PACE / CSCA — "Can it verify a real passport?" → No, not certifiably. Passive-auth chain (BAC, DG read, SOD, ASN.1/CMS verify) is implemented + unit-tested; PACE crypto deliberately unimplemented (no test doc), no real CSCA roots loaded. We built the constituent parts to prototype standard, not a certified system (named as future work).
2. Puzzle has no measured PAD — "How do you know it stops spoofing?" → No ISO 30107-3 benchmark for the Puzzle specifically (said openly in §5.8.3). Resistance is architectural (server-generated, unpredictable, session-bound, server-verified challenge a recording can't anticipate). Passive PAD measured in the companion study; Puzzle's empirical benchmark is future work; the ISO harness exists in code.
3. §5.8.3 harness/protocol — In practice-and-test/fivucsas-test (origin/main), by Ayşe Gülsüm Eren. Enroll public gallery → L2-norm Facenet512 cosine pairs → AUC/EER at 0.45 (benchmark) vs 0.4 (production). LFW 5,600 / CFP-FP 1,378 / AgeDB-30 5,084. Embedding model in isolation, not end-to-end; off-frontal/age degradation (EER ~27%/~34%) reported honestly.
4. Admin-override red gate — "Why trust the numbers?" → Override was a one-time repair-sprint exception, disclosed in §5.2; continue-on-error removed so isolation tests now hard-block, override leaves a GitHub audit trail. Test counts from grep over source, not CI tables; unit suite 1,670 pass / 0 fail on JDK 21.
5. Single-VPS / RLS-inert / fingerprint-removed / iris-stub / watchlist-stub vs ambitious framing → We name every gap (§7.2.2). "Architecturally complete + deployed, pre-certification + pre-commercial." Operative isolation = @filter + JWT-rebound context (tested 3 levels); fingerprint = WebAuthn (real); iris/watchlist = labeled stubs.
6. Client-side embedding on untrusted browser weakens security? → No: D2 = browser untrusted, verdict always server-side. Client computes the embedding so the raw image never leaves; only the non-invertible 512-vector crosses; server re-verifies cosine distance vs enrollment. Same model as WebAuthn (key never leaves device, assertion verified server-side). Data-minimisation gain; decision boundary unmoved.
7. Novel vs integration? → Chiefly integration, done to a completeness that yields novel artefacts: the 24-challenge two-channel Puzzle + server geometric re-scoring + anti-replay + open browser tester as a shipped system; the ISO 30107-3 harness with bootstrap CIs in-codebase; the @filter+JWT isolation continuously CI-asserted. Scientific novelty modest+targeted; engineering novelty = completeness + care. Appropriate for undergrad.
8. Why Facenet512 not ArcFace/AdaFace? → Host has no GPU; ArcFace needs one. ALLOW_HEAVY_ML=false is a deliberate boot guard. Facenet512 is CPU-safe, LFW AUC 0.9943; degradation documented; ArcFace upgrade + dual-write re-enrollment named in §7.3.
9. k6 thresholds = targets, real numbers? → One measured snapshot (June poster): verify p95 ~410ms, auth ~66ms, JWKS ~62ms on CX43 light load. Full instrumented campaign = future work; "1000+ users" compose-header = design estimate, not benchmark.
10. RLS migrations inert — why publish? → Authored early as defense-in-depth; found unenforced (superuser session bypassed). Rather than ship silently-broken security, documented + fell back to @filter (tested). Migrations append-only so kept; fixing RLS roles named as future work.
11. Gate bypass history — trust going forward? → Disclosed (§5.2); continue-on-error removed; 5 isolation ITs asserted-to-have-executed each merge; ArchUnit second non-bypassable layer in the fast lane. Hardened, not declared perfect.
12. KVKK/GDPR compliance — legal review? → No formal DPO/legal review; engineering controls mapped to statute (encryption at rest+transit, per-tenant consent, self-service delete/export, isolation, audit logs). Engineering claim, not a legal one.
13. All 12 methods usable in the live demo? → Live+verified: password, TOTP, email/SMS OTP, passkey/WebAuthn, QR approve-login, NFC-serial enroll; voice wired. eMRTD chip-login needs the Android NFC client + chip doc (not browser). Watchlist/address-proof = stubs. Demo: identifier-first web login + Puzzle on verify.fivucsas + Android NFC enroll.

What to have ready to demo

1. verify.fivucsas.com (Marmara tenant) identifier-first login, incognito, known demo account.
2. The Puzzle live — let a juror try a phone-screen photo → rejected (EAR veto / MiniFASNet).
3. amispoof.fivucsas.com — printed photo/screen → SPOOF; live face → REAL.
4. GitHub Actions last green run — isolation test job + surefire assertion (answers "trust the isolation guarantee").
5. spoof-detector src/metrics/iso30107.py open — APCER/BPCER/ACER/EER in code with bootstrap CIs.
6. Signed APK on a device — NFC enroll vs e-passport/e-ID; else visual card-detection + explain the distinction.

How to open (lead points)

1. State honest scope: one engineering question (can face verify + anti-spoof + multi-tenant isolation combine in one deployable CPU-only SaaS?) → yes, running + open-source; architectural/engineering claims, targets labeled.
2. Define "prototype" = architecturally complete + deployed, pre-certification + pre-commercial; gaps documented not hidden.
3. Signature contribution + its limit in one sentence (Puzzle = randomized server-verified two-channel active liveness, 24-challenge; resistance architectural; empirical PAD = first future-work item; harness already in code).
4. Anchor credibility in test discipline (4,400 authored; 3 isolation ITs CI-asserted-to-run against real PostgreSQL each merge).

Source: Sonnet defense-prep agent 2026-06-13. Pairs with thesis-review #188.