From cf58d739ffbcbfbef7b1b3625e29a9fc2a3787cf Mon Sep 17 00:00:00 2001 From: Ahmet Abdullah Gultekin Date: Thu, 11 Jun 2026 20:49:44 +0000 Subject: [PATCH] docs: correct customer/adoption claims + delete stale infra-contradicting decks Applies the SAFE subset of truth-audit 14_truth_audit.md to the docs repo. Fixes: - plans/BAAS_RENTAL_MODEL.md (P1-4): "has evolved from a university project into a production-grade biometric platform ... The next commercial step is" -> "a university capstone biometric platform ... could be extended commercially by". Removes the realized-evolution claim; doc stays a labelled Pre-Implementation design. - adr/0001-hosted-first-oidc.md (P1-5): "surfaces that real customers need to cover" -> "surfaces that real-world integrations need to cover" (no existing customer base). - README.md (P3-4): stale footer "Last Updated 2026-02-17" -> 2026-06-11 (body already current to June 2026). Deletions (verified dead: zero inbound references, not served by the VitePress book, contradict current prod on nearly every fact): - presentations/SPRING_2026_FINAL_PRESENTATION.md (P2-2/P1-1): GTX 1650 / GhostFaceNet, HS512, NGINX gateway, V24, public bio.fivucsas.com, 99.83%/99.65% LFW accuracy as if measured. Actual: GPU-less Hetzner CX43, RS256 OIDC, Traefik, V84, no public bio route. - presentations/SPRING_2026_SPEECHES.md (P2-2): Google Cloud / Europe Central 2, laptop-GPU via Cloudflare Tunnel, 200ms GTX 1650, HS512. All false vs prod. --- README.md | 2 +- adr/0001-hosted-first-oidc.md | 2 +- plans/BAAS_RENTAL_MODEL.md | 2 +- .../SPRING_2026_FINAL_PRESENTATION.md | 673 ------------------ presentations/SPRING_2026_SPEECHES.md | 448 ------------ 5 files changed, 3 insertions(+), 1124 deletions(-) delete mode 100644 presentations/SPRING_2026_FINAL_PRESENTATION.md delete mode 100644 presentations/SPRING_2026_SPEECHES.md diff --git a/README.md b/README.md index 6928308..c93f170 100644 --- a/README.md +++ b/README.md @@ -285,6 +285,6 @@ See design documentation: --- -**Documentation Last Updated:** 2026-02-17 +**Documentation Last Updated:** 2026-06-11 **Documentation Version:** 2.4 (Added Multi-Modal Authentication Module) **Project Version:** 1.0.0-SNAPSHOT diff --git a/adr/0001-hosted-first-oidc.md b/adr/0001-hosted-first-oidc.md index 29e685d..be56163 100644 --- a/adr/0001-hosted-first-oidc.md +++ b/adr/0001-hosted-first-oidc.md @@ -6,7 +6,7 @@ ## Context -FIVUCSAS originally shipped as an embeddable iframe widget that tenants dropped into their site, with the user typing credentials and completing MFA inside the iframe. The widget proved brittle across the surfaces that real customers need to cover: +FIVUCSAS originally shipped as an embeddable iframe widget that tenants dropped into their site, with the user typing credentials and completing MFA inside the iframe. The widget proved brittle across the surfaces that real-world integrations need to cover: - **Web NFC** cannot be used inside a cross-origin iframe — the spec restricts the API to top-level browsing contexts. NFC-driven authentication (Turkish e-ID, MRZ-bearing documents) was effectively dead in-iframe. - **WebAuthn / passkeys** suffer cross-origin edge cases. Cross-origin iframes carry restrictive Permissions Policy defaults, and even with `publickey-credentials-get` delegated, Safari and several embedded webviews refuse the request. diff --git a/plans/BAAS_RENTAL_MODEL.md b/plans/BAAS_RENTAL_MODEL.md index 086bd75..142a07b 100644 --- a/plans/BAAS_RENTAL_MODEL.md +++ b/plans/BAAS_RENTAL_MODEL.md @@ -28,7 +28,7 @@ ## 1. Executive Summary -FIVUCSAS has evolved from a university project into a production-grade biometric platform with 10 authentication methods, identity verification, and an embeddable auth widget. The next commercial step is offering individual biometric capabilities as rentable APIs -- Biometrics as a Service (BaaS). Developers should be able to sign up, get an API key, and call `POST /v1/face/verify` without deploying any infrastructure. This document defines the pricing tiers (Free/Developer/Enterprise), API gateway architecture with per-key rate limiting, feature isolation model, usage metering pipeline, SDK distribution strategy (npm, Maven Central, CocoaPods), and developer portal experience. The target is to make FIVUCSAS as easy to integrate as Stripe is for payments. +FIVUCSAS, a university capstone biometric platform with 10 authentication methods, identity verification, and an embeddable auth widget, could be extended commercially by offering individual biometric capabilities as rentable APIs -- Biometrics as a Service (BaaS). Developers should be able to sign up, get an API key, and call `POST /v1/face/verify` without deploying any infrastructure. This document defines the pricing tiers (Free/Developer/Enterprise), API gateway architecture with per-key rate limiting, feature isolation model, usage metering pipeline, SDK distribution strategy (npm, Maven Central, CocoaPods), and developer portal experience. The target is to make FIVUCSAS as easy to integrate as Stripe is for payments. --- diff --git a/presentations/SPRING_2026_FINAL_PRESENTATION.md b/presentations/SPRING_2026_FINAL_PRESENTATION.md deleted file mode 100644 index 3a233e5..0000000 --- a/presentations/SPRING_2026_FINAL_PRESENTATION.md +++ /dev/null @@ -1,673 +0,0 @@ -# FIVUCSAS - CSE4197 Engineering Project 2 Final Presentation - -**Date:** Spring 2026 (TBD) -**Duration:** 15 minutes + 5 minutes Q&A -**Language:** English -**Course:** CSE4197 Engineering Project 2 -**Last Updated:** 2026-03-28 - ---- - -## Presenter Distribution - -| Presenter | Slides | Time | Content | -|-----------|--------|------|---------| -| **Aysenur Arici** | 1-6 | ~5:00 | Title, Outline, Recap, Multi-Modal Auth Architecture, Anti-Spoofing, ML Pipeline | -| **Ahmet Abdullah Gultekin** | 7-13 | ~5:30 | Identity Core API, Auth Handlers, Embeddable Widget, OAuth 2.0, Web Dashboard, Deployment, Live Demo | -| **Ayse Gulsum Eren** | 14-20 | ~5:30 | Mobile/Desktop App, NFC Integration, Testing, Platform Stats, Challenges, Future Work, Q&A | - ---- - -# SLIDE 1 — TITLE - -**Face and Identity Verification Using Cloud-based SaaS Models** -**(FIVUCSAS)** - -CSE4197 Engineering Project 2 — Final Defense - ---- - -**Team:** -- Ahmet Abdullah Gultekin (150121025) -- Ayse Gulsum Eren (150120005) -- Aysenur Arici (150123825) - -**Advisor:** Assoc. Prof. Dr. Mustafa Agaoglu - -Marmara University - Faculty of Technology -Department of Computer Engineering - -Spring 2026 - ---- - -# SLIDE 2 — OUTLINE - -**Presentation Outline** - -| # | Topic | Presenter | -|---|-------|-----------| -| 1 | First Semester Recap | Aysenur | -| 2 | Multi-Modal Authentication Architecture | Aysenur | -| 3 | Anti-Spoofing & Liveness Detection | Aysenur | -| 4 | ML Pipeline & Face Recognition | Aysenur | -| 5 | Identity Core API — 10 Auth Handlers | Ahmet | -| 6 | Embeddable Auth Widget — "Stripe Elements for Biometrics" | Ahmet | -| 7 | OAuth 2.0 / OIDC Standard Protocol Support | Ahmet | -| 8 | Web Admin Dashboard & Auth Flow Builder | Ahmet | -| 9 | Deployment, CI/CD & Infrastructure | Ahmet | -| 10 | Live System Demo | Ahmet | -| 11 | Mobile & Desktop Applications | Gulsum | -| 12 | NFC Document Verification | Gulsum | -| 13 | Testing Strategy & Platform Stats | Gulsum | -| 14 | Challenges, Lessons & Future Work | Gulsum | - ---- - -# SLIDE 3 — FIRST SEMESTER RECAP (Aysenur) - -**What We Built in Semester 1 (CSE4297)** - -| Component | Status | Key Achievement | -|-----------|--------|-----------------| -| Biometric Processor API | 100% | 46+ endpoints, 9 ML models | -| Demo GUI | 100% | 14 interactive pages (Next.js) | -| Database Schema | 100% | PostgreSQL + pgvector, 14 migrations | -| Identity Core API | 85% | JWT auth, RBAC, multi-tenancy | -| NFC Readers | 85% | Turkish eID + Universal reader | -| Mobile App | 50% | KMP shared logic + Android UI | -| Documentation | 100% | Architecture, API docs, guides | - -**Semester 2 Focus:** Complete auth system, deploy to production, embeddable widget, OAuth 2.0, testing, mobile integration - ---- - -# SLIDE 4 — MULTI-MODAL AUTH ARCHITECTURE (Aysenur) - -**10-Method Authentication System** - -``` -┌─────────────────────────────────────────────────┐ -│ Auth Flow Engine │ -│ │ -│ Tenant-Configurable Multi-Step Authentication │ -│ │ -│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ -│ │ PASSWORD │ │ FACE │ │ EMAIL_OTP │ │ -│ └──────────┘ └──────────┘ └──────────────┘ │ -│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ -│ │ SMS_OTP │ │ TOTP │ │ QR_CODE │ │ -│ └──────────┘ └──────────┘ └──────────────┘ │ -│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ -│ │ FINGER │ │ VOICE │ │ HARDWARE_KEY │ │ -│ └──────────┘ └──────────┘ └──────────────┘ │ -│ ┌──────────────┐ │ -│ │ NFC_DOCUMENT │ │ -│ └──────────────┘ │ -└─────────────────────────────────────────────────┘ -``` - -**Key Innovation:** -- Each tenant configures which auth methods to use per operation type -- 9 operation types: APP_LOGIN, API_ACCESS, DOOR_ACCESS, PAYMENT, etc. -- PASSWORD mandatory for APP_LOGIN/API_ACCESS (device constraint enforcement) -- Runtime flow validation at session start - ---- - -# SLIDE 5 — ANTI-SPOOFING & LIVENESS (Aysenur) - -**The Biometric Puzzle — Active Liveness Detection** - -| Method | Technique | Purpose | -|--------|-----------|---------| -| Blink Detection | Eye Aspect Ratio (EAR) | Verify eye movement | -| Smile Detection | Mouth Aspect Ratio (MAR) | Verify facial control | -| Head Pose | Pitch, Yaw, Roll estimation | Verify 3D presence | -| Random Sequence | Challenge generation | Prevent replay attacks | - -**Passive Anti-Spoofing (DeepFace 0.0.98):** -- Built-in anti-spoofing with configurable threshold -- Texture analysis (LBP patterns) -- Color distribution and frequency domain analysis -- Moire pattern detection for screen photos - -**Browser-Side Face Detection (MediaPipe Tasks API):** -- Real-time face quality check before capture -- Bounding box guide, "Move closer" / "Better lighting" hints -- Face cropping before upload (smaller payload, better privacy) - ---- - -# SLIDE 6 — ML PIPELINE & FACE RECOGNITION (Aysenur) - -**9 Integrated ML Models** - -| Model | Dimension | Purpose | -|-------|-----------|---------| -| FaceNet | 128-D | Default recognition | -| FaceNet512 | 512-D | High accuracy | -| ArcFace | 512-D | State-of-the-art | -| VGG-Face | 2622-D | High dimensional | -| GhostFaceNet | 512-D | Lightweight (new) | -| MediaPipe | 468 points | Facial landmarks | -| Dlib | 68 points | Alternative landmarks | -| YOLOv8 | - | Card/document detection | -| Custom CNN | - | Passive liveness | - -**Vector Search Pipeline:** -1. Face detected (RetinaFace / MTCNN) -2. Anti-spoofing check (DeepFace built-in) -3. Embedding extracted (configurable model) -4. Stored in PostgreSQL pgvector (HNSW index) -5. 1:N search via cosine similarity - -**Performance:** ~200ms per face verification on GTX 1650 - ---- - -# SLIDE 7 — IDENTITY CORE API (Ahmet) - -**Spring Boot 3.2 + Java 21 — Production Ready** - -| Feature | Details | -|---------|---------| -| Architecture | Hexagonal (Ports & Adapters) | -| Authentication | JWT (HS512) + Refresh Tokens | -| Authorization | RBAC with @PreAuthorize | -| Multi-Tenancy | Row-level security via tenant_id | -| Auth Handlers | 10 methods (Password → NFC), all production-ready | -| OAuth 2.0 / OIDC | authorize, token, userinfo, discovery, JWKS | -| Database | PostgreSQL 16 + pgvector, 24 Flyway migrations (V1-V24) | -| Testing | 304 unit tests + 24 integration tests pass | -| API Docs | Swagger UI (OpenAPI 3.0) | - -**Database Schema (V24):** -- 25+ tables across identity, auth, biometric, OAuth domains -- Auth flow system: 8 tables for configurable multi-step auth -- OAuth 2.0 tables: oauth2_clients, oauth2_authorization_codes (V24) -- Step-up auth: user_devices with ECDSA P-256 (V17) -- Sample data: 3 tenants, 8 users, audit log entries - -**Deployed:** https://api.fivucsas.com (Hetzner CX43, 8CPU/16GB) - ---- - -# SLIDE 8 — 10 AUTH HANDLERS (Ahmet) - -**Complete Implementation Details** - -| # | Handler | Technology | Status | -|---|---------|-----------|--------| -| 1 | PasswordAuthHandler | BCrypt + Spring Security | Production | -| 2 | FaceAuthHandler | BiometricServicePort → FastAPI | Production | -| 3 | EmailOtpAuthHandler | SMTP + Redis (5-min TTL) | Production | -| 4 | QrCodeAuthHandler | WebSocket delegation | Production | -| 5 | TotpAuthHandler | dev.samstevens.totp + Redis | Production | -| 6 | SmsOtpAuthHandler | SmsService interface (Twilio ready) | Production | -| 7 | FingerprintAuthHandler | BiometricServicePort | Production | -| 8 | VoiceAuthHandler | BiometricServicePort | Production | -| 9 | HardwareKeyAuthHandler | com.yubico WebAuthn 2.5.2 | Production | -| 10 | NfcDocumentAuthHandler | Android NFC SDK (11K lines, 43 files) | Production | - -**Design Pattern:** Strategy pattern — each handler implements `AuthHandler` interface with `authenticate(session, step, payload)` method. Selected at runtime based on `AuthMethod` enum. - ---- - -# SLIDE 9 — EMBEDDABLE AUTH WIDGET (Ahmet) - -**"Stripe Elements for Biometrics" — Embeddable Authentication** - -**The Innovation:** No existing auth provider handles embedded biometric capture (camera, microphone). FIVUCSAS is the first to offer this as an embeddable widget. - -**3-Layer Architecture:** - -``` -Layer 1: Developer API (Web Component) - - -Layer 2: Orchestration (OAuth 2.0 + postMessage) - Creates/manages auth sessions via FIVUCSAS API - Coordinates multi-step flow via postMessage with iframe - -Layer 3: Secure Capture (iframe from verify.fivucsas.com) - Camera, microphone, WebAuthn run inside the iframe - Biometric data NEVER leaves the iframe - Only tokens/session IDs returned to host via postMessage -``` - -**Integration — Just 3 Lines (Script Tag):** -```html - - -``` - -**React Integration:** -```tsx -import { FivucsasProvider, VerifyButton } from '@fivucsas/auth-react'; - -function App() { - return ( - - { /* exchange */ }} /> - - ); -} -``` - -**KMP WebView Integration:** -- KMP apps load `verify.fivucsas.com/embed` in native WebView -- postMessage bridge works identically across Android/Desktop/iOS -- Native biometrics (fingerprint, NFC) handled natively, submitted to auth session API - -**Security Model:** - -| Concern | Solution | -|---------|----------| -| Biometric data isolation | Cross-origin iframe — host cannot access camera data | -| Token theft | Auth code flow — tokens never exposed to host JS | -| Clickjacking | CSP `frame-ancestors` whitelist per registered client | -| Replay attacks | Nonce in auth session, 30-second auth codes | -| CSRF | `state` parameter in OAuth 2.0 flow | - -**Key Insight:** 90% of the code already exists in our web-app (MultiStepAuthFlow, 10 step components, biometric engine). The widget extracts and packages this into an embeddable SDK. - -**Package Structure:** - -| Package | Size | Purpose | -|---------|------|---------| -| `@fivucsas/auth-js` | ~9.5KB | Core SDK (iframe, postMessage, tokens) | -| `@fivucsas/auth-elements` | ~8KB | Web Components (Lit) | -| `@fivucsas/auth-react` | ~3KB | React bindings | -| `@fivucsas/auth-kotlin` | - | KMP SDK for mobile/desktop | - ---- - -# SLIDE 10 — OAuth 2.0 / OIDC (Ahmet) - -**Standard Protocol Support — OAuth 2.0 + OpenID Connect** - -**Why OAuth 2.0?** -- Industry standard for authorization delegation -- Required for embeddable widget (third-party sites need token exchange) -- Enables FIVUCSAS as an Identity Provider (like e-Devlet, Google, Auth0) - -**Endpoints Implemented:** - -| Endpoint | Method | Purpose | -|----------|--------|---------| -| `/oauth2/authorize` | GET | Authorization request (redirect or iframe) | -| `/oauth2/token` | POST | Token exchange (auth code -> access + id tokens) | -| `/oauth2/userinfo` | GET | User profile (OIDC standard claims) | -| `/.well-known/openid-configuration` | GET | OIDC Discovery document | -| `/.well-known/jwks.json` | GET | JSON Web Key Set for token verification | - -**OIDC Discovery Document:** -```json -{ - "issuer": "https://api.fivucsas.com", - "authorization_endpoint": "https://api.fivucsas.com/oauth2/authorize", - "token_endpoint": "https://api.fivucsas.com/oauth2/token", - "userinfo_endpoint": "https://api.fivucsas.com/oauth2/userinfo", - "jwks_uri": "https://api.fivucsas.com/.well-known/jwks.json", - "response_types_supported": ["code"], - "subject_types_supported": ["public"], - "id_token_signing_alg_values_supported": ["RS256"], - "scopes_supported": ["openid", "profile", "email", "biometric"] -} -``` - -**Client Registration:** -- Developers register applications via Developer Portal -- Receive `client_id` and `client_secret` -- Configure redirect URIs and allowed scopes -- Per-client auth flow configuration (which biometric methods to require) - -**Token Flow:** -``` -1. Third-party redirects to /oauth2/authorize?client_id=...&scope=openid biometric -2. User completes multi-step auth (password + face + TOTP, etc.) -3. FIVUCSAS redirects back with authorization code -4. Third-party exchanges code for tokens via /oauth2/token -5. access_token grants API access, id_token contains user identity -``` - ---- - -# SLIDE 11 — WEB ADMIN DASHBOARD (Ahmet) - -**React 18 + TypeScript + Material-UI 5** - -| Page | Features | -|------|----------| -| Dashboard | Stats cards, system metrics, recent activity | -| Users | CRUD, role assignment, biometric status | -| Tenants | Create/edit, max users, contact info | -| Roles | Permission management | -| Auth Flows | Visual builder, operation type config, drag steps | -| Devices | User/tenant device listing | -| Enrollments | Biometric enrollment management | -| Audit Logs | Filterable by action, user, date range | -| Settings | Profile, security, notifications, appearance, i18n | -| Analytics | Pie, bar, area, radial charts (Recharts) | -| Auth Test | Live 11-section biometric auth test page | -| Widget Demo | Embeddable widget live preview | -| Developer Portal | SDK docs, integration guide, client registration | - -**Multi-Step Auth UI:** -- 10 step components (Password, Face, Email OTP, SMS, TOTP, QR, Fingerprint, Voice, Hardware Key, NFC) -- FaceCaptureStep: WebRTC + MediaPipe Tasks API for browser-side face detection -- StepProgress: MUI Stepper with method icons and status colors -- i18n: Full Turkish/English bilingual UI (i18next) -- Real-time notification panel with audit log polling - -**Deployed:** https://app.fivucsas.com - ---- - -# SLIDE 12 — DEPLOYMENT & CI/CD (Ahmet) - -**Production Infrastructure — Hetzner CX43 (8 CPU / 16GB RAM / 150GB SSD)** - -``` -┌──────────────────────┐ ┌──────────────────────────────────────┐ -│ Hostinger │ │ Hetzner VPS (CX43, Nuremberg) │ -│ │ │ │ -│ Web Dashboard │────▶│ Identity Core API (port 8080) │ -│ Landing Website │ │ Biometric API (port 8001, CPU mode) │ -│ Auth-Test Page │ │ PostgreSQL 16 + pgvector │ -│ │ │ Redis 7 │ -└──────────────────────┘ │ NGINX API Gateway │ - └──────────────────────────────────────┘ -``` - -| Service | URL | Hosting | -|---------|-----|---------| -| Web Dashboard | https://app.fivucsas.com | Hostinger | -| Widget Demo | https://app.fivucsas.com/widget-demo | Hostinger | -| Developer Portal | https://app.fivucsas.com/developer-portal | Hostinger | -| Landing Page | https://fivucsas.com | Hostinger | -| Identity API | https://api.fivucsas.com | Hetzner VPS | -| Biometric API | https://bio.fivucsas.com | Hetzner VPS | -| OIDC Discovery | https://api.fivucsas.com/.well-known/openid-configuration | Hetzner VPS | -| API Health | https://api.fivucsas.com/actuator/health | Hetzner VPS | - -**CI/CD:** GitHub Actions — 3 parallel jobs (Java 21 + Python 3.11 + Node 20) + Playwright E2E workflow -**Containers:** 12 Docker containers, all healthy (identity-core-api, biometric-api, postgres, redis, nginx, etc.) - ---- - -# SLIDE 13 — LIVE DEMO (Ahmet) - -**Demo Flow (2-3 minutes)** - -1. **Login** — Navigate to https://app.fivucsas.com, login with admin credentials -2. **Dashboard** — Show real-time stats (users, tenants, verifications, success rates) -3. **Users CRUD** — Create a test user, show tenant assignment -4. **Auth Flow Builder** — Create an APP_LOGIN flow with PASSWORD + FACE steps -5. **Auth Test Page** — Demonstrate live biometric auth (face, voice, fingerprint, TOTP) -6. **Widget Demo** — Show embeddable widget at /widget-demo (3-line integration) -7. **Developer Portal** — Show SDK documentation and client registration at /developer-portal -8. **OIDC Discovery** — Show https://api.fivucsas.com/.well-known/openid-configuration -9. **Swagger UI** — Show API documentation at /swagger-ui.html -10. **Biometric API Health** — Show https://bio.fivucsas.com/api/v1/health - -**Backup:** Screenshots embedded in slides in case of network issues - ---- - -# SLIDE 14 — MOBILE & DESKTOP APP (Gulsum) - -**Kotlin Multiplatform + Compose Multiplatform** - -| Platform | Screens | Status | -|----------|---------|--------| -| Android | Login, Register, Home, Enroll, Verify, Voice, Face Liveness, Card Detection | UI Complete | -| Desktop | Welcome, Enroll, Verify, Admin Dashboard | UI Complete | -| iOS | Framework ready | Pending | - -**Architecture:** -- Clean Architecture + MVVM -- Koin Dependency Injection -- Ktor HTTP Client -- 90% code sharing across platforms - -**Shared Module:** -- 10 Use Cases (LoginUseCase, EnrollFaceUseCase, VerifyFaceUseCase, etc.) -- 5 ViewModels -- API contracts (AuthApi, BiometricApi, IdentityApi) -- Production URLs configured (Hetzner + Biometric processor endpoints) -- i18n support, mocks removed, 6 new screens added (March 2026) - -**New Screens (March 2026):** VoiceVerifyScreen, FaceLivenessScreen, CardDetectionScreen - -**WebView Widget Integration:** KMP apps load embeddable widget in native WebView for biometric auth - -**Desktop Kiosk Mode:** Self-service enrollment/verification stations - ---- - -# SLIDE 15 — NFC DOCUMENT VERIFICATION (Gulsum) - -**Two NFC Reader Implementations** - -### UniversalNfcReader (60+ Kotlin files) -| Card Type | Authentication | -|-----------|---------------| -| Turkish eID | BAC with MRZ | -| e-Passport | BAC with TD3 MRZ | -| Istanbulkart | UID only | -| MIFARE Classic/DESFire/Ultralight | Key-based | -| NDEF Tags | Format-dependent | -| ISO 15693 (NfcV) | Varies | - -### TurkishEidNfcReader (Dedicated) -- PIN Verification (6-digit) -- Personal Data (DG1) + Photo (DG2/JPEG2000) -- SOD Signature Validation (Bouncy Castle) -- Material Design 3 UI - -**Standards:** ISO 14443-3/4, ISO 7816-4, ICAO Doc 9303 -**NFC codebase:** 11,089 lines across 43 files (integrated into client-apps) - ---- - -# SLIDE 16 — TESTING STRATEGY & PLATFORM STATS (Gulsum) - -**Multi-Layer Testing** - -| Layer | Framework | Count | Status | -|-------|-----------|-------|--------| -| Unit Tests (Backend) | JUnit 5 + Mockito | 304+ | All Pass | -| Auth Handler Tests | JUnit 5 | 30+ methods | All Pass | -| Constraint Tests | JUnit 5 | 4 tests | All Pass | -| Step-Up Auth Tests | JUnit 5 | 20 tests | All Pass | -| E2E Tests (Web) | Playwright | 247+ | 247 Pass, 7 Skipped | -| Integration Tests | TestContainers + PostgreSQL | 24 tests | All Pass | -| Vitest (Frontend) | Vitest | 171 tests | All Pass | -| Other Project Tests | Various | Sarnic 456, etc. | All Pass | - -**E2E Test Strategy:** -- Auth setup pattern: Single login, sessionStorage injection via `addInitScript` -- Eliminates rate limiting (HTTP 429) from repeated login attempts -- Tests against production: https://app.fivucsas.com -- Playwright CI workflow integrated into GitHub Actions - -**E2E Coverage (16+ spec files):** -- Login flow, Users CRUD, Auth Flow Builder, Multi-Step Auth -- Analytics page, Settings, Tenants, Roles, Devices -- Audit Logs, Enrollments, Auth Sessions, Auth Test page -- Widget Demo, Developer Portal - -**Platform Stats:** - -| Metric | Value | -|--------|-------| -| Auth methods production-ready | **10/10** | -| SDK size (auth-js) | **9.5KB**, zero dependencies | -| Unit tests passing | **304** | -| E2E tests passing | **247** | -| Frontend tests (Vitest) | **171** | -| OAuth 2.0 compliant | Yes (OIDC Discovery + JWKS) | -| Total lines of code | **~15,000+** across 4 repos | -| Docker containers (all healthy) | **12** | -| API endpoints | **46+** (Biometric) + **30+** (Identity) + **5** (OAuth) | -| Database migrations | **24** (V1-V24) | -| ML models integrated | **9** | -| Deployed services | **6** (Dashboard, Landing, Auth-Test, Identity API, Biometric API, OIDC) | -| Bilingual i18n | Turkish + English | - ---- - -# SLIDE 17 — CHALLENGES & SOLUTIONS (Gulsum) - -**Technical Challenges Encountered** - -| Challenge | Solution | -|-----------|----------| -| H2 doesn't support PostgreSQL types (text[], jsonb) | TestContainers with real PostgreSQL | -| E2E rate limiting (429 errors) | Auth setup pattern — login once, inject session | -| Flyway checksum mismatch on redeployment | `validate-on-migrate: false` for Docker profile | -| Audit log infinite loop | Fixed @Transactional/@Async conflict | -| Mixed content (HTTP/HTTPS) on deployed dashboard | CSP headers + HTTPS enforcement | -| Virtual camera injection for face spoofing | Multi-factor auth + anti-spoofing pipeline | -| 4GB VRAM constraint (GTX 1650) | GhostFaceNet + RetinaFace (lightweight models); also CPU-mode deployment | -| Cross-platform code sharing (Android/Desktop/iOS) | Kotlin Multiplatform — 90% shared | -| Biometric data in embedded widget (cross-origin) | Stripe-style iframe isolation — data never leaves iframe | -| WebAuthn fingerprint vs hardware key confusion | Separate flows: credentials.get() for fingerprint, server challenge for hardware key | -| AuthSession step completion data format | { data } wrapper fix — resolved all secondary auth failures | -| Biometric API memory (3GB limit, 94% usage) | Upgraded Hetzner CX33 to CX43 (16GB RAM) | - ---- - -# SLIDE 18 — LESSONS LEARNED (Gulsum) - -**Key Takeaways** - -1. **Hexagonal Architecture pays off** — Changing from NoOp SMS to Twilio requires zero domain code changes -2. **Strategy Pattern for auth handlers** — Adding a new auth method = 1 new class + register in enum -3. **Browser-side ML is viable** — MediaPipe Tasks API runs face detection at 30fps in-browser -4. **Multi-tenant design from day one** — Retrofitting tenant isolation is extremely costly -5. **E2E tests save deployment time** — Caught 3 production bugs before manual testing -6. **CI/CD is essential** — GitHub Actions catches build failures within minutes -7. **pgvector enables SQL-native ML** — No separate vector database needed -8. **Embed with iframes, not SDKs** — Stripe's iframe model is ideal for sensitive biometric data -9. **OAuth 2.0 is table stakes** — Every auth platform must support standard protocols for adoption -10. **Dogfooding validates architecture** — Using our own widget in our own dashboard proves it works - ---- - -# SLIDE 19 — FUTURE WORK & CONCLUSION (Gulsum) - -**Remaining & Future Enhancements** - -| Priority | Task | Status | -|----------|------|--------| -| High | Web Components (`@fivucsas/auth-elements`) packaging | In Progress | -| High | Widget dogfooding — use own widget in web-app login | In Progress | -| High | Mobile app backend integration tests | URLs configured | -| Medium | SMS gateway (Twilio) production activation | Code ready | -| Medium | Client-side ONNX card detection (replacing server YOLO) | Done (web-app #111; server YOLO card path removed) | -| Low | ISO/IEC 30107 compliance certification | Future | -| Low | Full WebAuthn attestation (CBOR) | Research | -| Future | iOS app UI implementation | Framework ready | -| Future | Multi-region deployment (HA) | Architecture designed | - -**Final Project Metrics:** - -| Metric | Value | -|--------|-------| -| Total source files | 400+ | -| Backend endpoints | 46+ (Biometric) + 30+ (Identity) + 5 (OAuth) | -| ML models integrated | 9 | -| Auth methods (all production-ready) | **10/10** | -| Database migrations | 24 (V1-V24) | -| Unit tests | 304 | -| E2E tests | 247 | -| Frontend tests (Vitest) | 171 | -| Docker containers (all healthy) | 12 | -| Deployed services | 6 (Dashboard, Landing, Auth-Test, Identity API, Biometric API, OIDC) | -| SDK size | 9.5KB, zero dependencies | -| Lines of code | ~15,000+ across 4 repos | -| OAuth 2.0 / OIDC | Fully compliant | -| i18n | Turkish + English | - ---- - -# SLIDE 20 — THANK YOU & Q&A - -**Thank You** - -**FIVUCSAS** — Face and Identity Verification Using Cloud-Based SaaS Models - -**Live System URLs:** - -| Service | URL | -|---------|-----| -| Dashboard | https://app.fivucsas.com | -| Widget Demo | https://app.fivucsas.com/widget-demo | -| Developer Portal | https://app.fivucsas.com/developer-portal | -| Landing Page | https://fivucsas.com | -| API Health | https://api.fivucsas.com/actuator/health | -| Biometric API | https://bio.fivucsas.com/api/v1/health | -| OIDC Discovery | https://api.fivucsas.com/.well-known/openid-configuration | -| Swagger UI | https://api.fivucsas.com/swagger-ui.html | - -**Repository:** github.com/Rollingcat-Software/FIVUCSAS - -**Questions?** - ---- - -## References - -1. Schroff, F., Kalenichenko, D., & Philbin, J. (2015). FaceNet: A Unified Embedding for Face Recognition and Clustering. CVPR. -2. Deng, J., Guo, J., Xue, N., & Zafeiriou, S. (2019). ArcFace: Additive Angular Margin Loss for Deep Face Recognition. CVPR. -3. Serengil, S. I., & Ozpinar, A. (2024). A Benchmark of Facial Recognition Pipelines and Co-Usability Performances of Modules. Journal of Information Technologies. -4. ISO/IEC 30107-3:2023. Biometric presentation attack detection. -5. ICAO Doc 9303. Machine Readable Travel Documents. -6. Lugaresi, C., et al. (2019). MediaPipe: A Framework for Building Perception Pipelines. CVPR Workshop. -7. European Parliament. (2024). EU Artificial Intelligence Act. Regulation (EU) 2024/1689. -8. OWASP. (2023). OWASP Top 10 Web Application Security Risks. -9. Evans, C., et al. (2024). Spring Boot 3.2 Reference Documentation. VMware. -10. Tiangolo, S. (2024). FastAPI Documentation. https://fastapi.tiangolo.com - ---- - -## Q&A Preparation — Anticipated Questions - -### Q: How do you prevent deepfake attacks? -**A:** Multi-layered approach: (1) Active liveness — random facial action sequence (blink, smile, head turn), (2) Passive anti-spoofing — DeepFace 0.0.98 built-in detection, (3) Browser-side MediaPipe face detection for real-time quality checks, (4) Multi-factor auth makes face-only attacks insufficient. - -### Q: Why not use a cloud biometric service (Azure, AWS)? -**A:** FIVUCSAS is designed as an open-source, self-hosted alternative. We integrate 9 ML models locally, giving full control over data privacy (no biometric data leaves the organization). Cloud services are vendor-locked and expensive at scale. - -### Q: How does multi-tenancy work? -**A:** Every table includes a `tenant_id` foreign key. JPA queries are tenant-scoped. Each tenant can configure their own auth flows, user limits, and biometric settings independently. Row-level security ensures data isolation. - -### Q: What's the face recognition accuracy? -**A:** Depends on model. ArcFace: 99.83% on LFW benchmark. FaceNet512: 99.65%. Our system uses cosine similarity with configurable thresholds (default 0.6 for verification, 0.4 for search). - -### Q: Why Kotlin Multiplatform instead of Flutter? -**A:** KMP provides native performance on Android (direct JVM), shared business logic with type safety, and Compose Multiplatform offers native UI on both Android and Desktop. The 90% code sharing ratio is comparable to Flutter with better Android integration. - -### Q: How do you handle the 4GB VRAM limitation? -**A:** We use lightweight models: GhostFaceNet for recognition (512-D, ~100MB), RetinaFace for detection (~30MB). Total GPU memory usage stays under 2GB, leaving headroom for concurrent requests. - -### Q: What happens if the biometric processor is offline? -**A:** The Identity Core API returns a graceful error. Auth flows that include face verification will fail at that step, but password-based flows continue to work. The architecture is designed for service independence. - -### Q: How do you ensure GDPR/KVKK compliance? -**A:** (1) Only embeddings stored, never raw images, (2) Existing delete endpoints for right to erasure, (3) Audit trail for all operations, (4) Multi-tenant isolation prevents cross-organization data access, (5) Purpose limitation — biometric data used only for authentication. - -### Q: How does the embeddable widget protect biometric data on third-party sites? -**A:** We use Stripe's iframe isolation model. The widget runs inside a cross-origin iframe from verify.fivucsas.com. Camera and microphone access is confined to the iframe. The host page never sees raw biometric data — only authorization codes are returned via postMessage. This is the same architecture Stripe uses to protect credit card numbers. - -### Q: Why OAuth 2.0 instead of a custom token system? -**A:** OAuth 2.0 is the industry standard for authorization delegation. It enables FIVUCSAS to serve as a full Identity Provider — any third-party application can integrate using standard libraries (like passport.js, Spring Security OAuth). OIDC adds identity claims (who the user is). This makes adoption easy because developers already know the protocol. - -### Q: How does the 9.5KB SDK compare to alternatives? -**A:** Auth0 Lock is ~400KB, Firebase Auth UI is ~100KB, Keycloak.js is ~20KB. Our SDK is 9.5KB with zero dependencies because we delegate all heavy work (UI, biometric capture, auth flow orchestration) to the hosted iframe. The SDK only handles iframe lifecycle and postMessage communication. - -### Q: Can the widget handle all 10 auth methods? -**A:** Yes. The widget extracts the same MultiStepAuthFlow component and all 10 step components from our web-app. Face, voice, fingerprint (WebAuthn), hardware key, TOTP, QR code — they all work inside the iframe. The tenant's configured auth flow determines which steps appear. diff --git a/presentations/SPRING_2026_SPEECHES.md b/presentations/SPRING_2026_SPEECHES.md deleted file mode 100644 index 9900455..0000000 --- a/presentations/SPRING_2026_SPEECHES.md +++ /dev/null @@ -1,448 +0,0 @@ -# FIVUCSAS Spring 2026 — Speaker Notes - -**Date:** Spring 2026 (TBD) -**Duration:** 15 minutes + 5 minutes Q&A -**Total Slides:** 18 - ---- - -## Presenter Distribution - -| Presenter | Slides | Time | -|-----------|--------|------| -| **Aysenur Arici** | 1-6 | ~5:00 | -| **Ahmet Abdullah Gultekin** | 7-12 | ~5:00 | -| **Ayse Gulsum Eren** | 13-18 | ~5:00 | - ---- - -# AYSENUR ARICI (Slides 1-6) - ---- - -## SLIDE 1: Title (25 sec) - -``` -Good morning everyone. We are presenting the final defense of FIVUCSAS — -Face and Identity Verification Using Cloud-Based SaaS Models. - -I am Aysenur Arici. With me are Ahmet Abdullah Gultekin and Ayse Gulsum -Eren. Our project advisor is Associate Professor Doctor Mustafa Agaoglu. - -This is our second semester defense for CSE4197 Engineering Project 2. -``` - ---- - -## SLIDE 2: Outline (25 sec) - -``` -Our presentation covers three sections. - -First, I will recap our first semester work and present the multi-modal -authentication architecture, anti-spoofing system, and ML pipeline. - -Then Ahmet will demonstrate the Identity Core API, web dashboard, and -deployment infrastructure with a live demo. - -Finally, Gulsum will cover the mobile application, NFC readers, testing -strategy, and future work. -``` - ---- - -## SLIDE 3: First Semester Recap (45 sec) - -``` -In our first semester, we built the core platform components. - -The Biometric Processor API with 46 endpoints and 9 machine learning -models was completed. We built 14 interactive demo pages with Next.js. - -The database schema with PostgreSQL and pgvector for face embeddings -was finalized with 14 Flyway migrations. - -The Identity Core API was at 85 percent — basic JWT auth and RBAC -were working, but the multi-modal auth system was not yet implemented. - -For the second semester, our focus was: complete the auth system, -deploy everything to production, add comprehensive testing, and -integrate the mobile application. -``` - ---- - -## SLIDE 4: Multi-Modal Auth Architecture (60 sec) - -``` -The centerpiece of our second semester work is the multi-modal -authentication system. - -We implemented 10 authentication methods — from password and face -recognition to hardware keys and NFC documents. - -The key innovation is tenant-configurable auth flows. Each -organization using our platform can define their own authentication -steps for different operations. - -For example, a bank's APP_LOGIN might require password plus face -verification, while their DOOR_ACCESS might only need a hardware key. - -We enforce device constraints — PASSWORD is mandatory as the first -step for APP_LOGIN and API_ACCESS operations. But for physical -operations like DOOR_ACCESS, tenants have full freedom. - -The system uses the Strategy pattern — each auth method is a separate -handler class. Adding a new method requires just one new class and -registering it in the enum. Zero changes to existing code. -``` - ---- - -## SLIDE 5: Anti-Spoofing & Liveness (50 sec) - -``` -Anti-spoofing is critical for any biometric system. - -Our Biometric Puzzle is an active liveness detection algorithm. It -generates a random sequence of facial actions — blink, smile, look -left, look right. The user must perform these actions in the correct -order, proving they are live and present. - -On the passive side, we upgraded to DeepFace version 0.0.98 which -includes built-in anti-spoofing. It detects texture patterns, -color distributions, and moire patterns from photos of screens. - -A significant addition this semester is browser-side face detection -using Google's MediaPipe Tasks API. Before the user even captures -their photo, the browser detects if a face is present, centered, -and well-lit. This improves user experience and reduces server load. -``` - ---- - -## SLIDE 6: ML Pipeline (45 sec) - -``` -Our system integrates 9 machine learning models. - -For face recognition, we support FaceNet, ArcFace, VGG-Face, and the -newly added GhostFaceNet — which is lightweight enough for our 4GB -GPU. - -For detection, we use RetinaFace as the default, with MTCNN, YOLO v8 -through v12, and CenterFace as alternatives. - -The vector search pipeline works as follows: a face is detected, -anti-spoofing is checked, an embedding is extracted, and then stored -or compared using PostgreSQL pgvector with HNSW indexing. - -Verification takes approximately 200 milliseconds on our GTX 1650. - -Now I will hand over to Ahmet for the Identity Core API and live demo. -``` - ---- - -# AHMET ABDULLAH GULTEKIN (Slides 7-12) - ---- - -## SLIDE 7: Identity Core API (50 sec) - -``` -Thank you Aysenur. - -The Identity Core API is built with Spring Boot 3.2 and Java 21, -following hexagonal architecture with ports and adapters. - -It provides JWT authentication with HS512, role-based access control -with PreAuthorize annotations, and multi-tenant isolation via -tenant ID foreign keys on every table. - -The database has 16 Flyway migrations creating over 20 tables. The -V16 migration alone added 8 tables for the configurable auth flow -system — auth methods, tenant auth methods, auth flows, auth flow -steps, auth sessions, session steps, user devices, and enrollments. - -We have 508 unit tests passing. The API is deployed and running on -a Google Cloud Platform virtual machine in the Europe Central 2 region. -``` - ---- - -## SLIDE 8: 10 Auth Handlers (50 sec) - -``` -All 10 authentication handlers are implemented and tested. - -Password uses BCrypt with Spring Security. Face verification calls -our biometric processor via REST. Email OTP sends codes via SMTP -with a 5-minute expiry in Redis. - -QR Code authentication uses WebSocket delegation — the user scans -a QR on their phone, and the desktop session updates in real-time. - -TOTP wraps the samstevens library and stores secrets in Redis. -SMS OTP uses an abstracted SmsService interface — currently using -a no-op implementation, but Twilio integration code is ready. - -Fingerprint and Voice verification route through the -BiometricServicePort adapter to our FastAPI service. - -Hardware Key uses the Yubico WebAuthn library version 2.5.2 for -FIDO2 challenge-response authentication. - -NFC Document is a stub handler awaiting physical hardware integration. -``` - ---- - -## SLIDE 9: Web Dashboard (45 sec) - -``` -The web admin dashboard is built with React 18, TypeScript, and -Material UI 5. - -It features a dashboard with real-time statistics, users CRUD with -role assignment, tenant management, and an audit log viewer with -filters. - -The Auth Flow Builder is a visual tool where administrators can -create authentication flows. They select an operation type, add -steps like password, face, and OTP, and the system enforces -constraints automatically. - -The Multi-Step Authentication UI has 10 step components. The Face -Capture step uses WebRTC for camera access and MediaPipe for -browser-side face detection. - -The dashboard supports dark mode, internationalization in Turkish -and English, and is deployed to Hostinger at the URL shown. -``` - ---- - -## SLIDE 10: Deployment & CI/CD (45 sec) - -``` -Our deployment uses three hosting platforms. - -The web dashboard and landing page are on Hostinger with static -file hosting. The Identity Core API runs on a GCP virtual machine -with Docker — alongside PostgreSQL and Redis containers. - -The biometric processor runs on my laptop GPU through a Cloudflare -Tunnel, making it accessible via HTTPS from anywhere. - -Our CI/CD pipeline uses GitHub Actions with three parallel jobs — -Java 21 for the backend, Python 3.11 for the biometric processor, -and Node 20 for the web dashboard. Each push triggers automated -builds and tests. -``` - ---- - -## SLIDE 11: Live Demo (2-3 min) - -``` -Let me show you the live system. - -[Navigate to app.fivucsas.com] - -This is the login page. I will sign in with the admin account. - -[Login and show dashboard] - -The dashboard shows our platform statistics — total users, active -users, tenants, biometric enrollment rates, and authentication -success rates. - -[Navigate to Users] - -Here we can manage users — create, edit, assign roles and tenants. - -[Navigate to Auth Flows] - -This is the Auth Flow Builder. Let me create a new flow for -APP_LOGIN. Notice how PASSWORD is automatically added as the -first step — this is our device constraint enforcement. - -[Navigate to Audit Logs] - -All operations are logged. I can filter by action type, user, -and date range. - -[Show Swagger UI] - -Finally, the full API documentation is available at swagger-ui. - -Now I hand over to Gulsum. -``` - ---- - -# AYSE GULSUM EREN (Slides 13-18) - ---- - -## SLIDE 12: Mobile & Desktop App (50 sec) - -``` -Thank you Ahmet. - -Our mobile and desktop applications are built with Kotlin -Multiplatform and Compose Multiplatform. - -On Android, we have Login, Register, Home, Enroll, and Verify -screens with CameraX integration for face capture. - -The Desktop application includes a Welcome screen with mode -selection, self-service enrollment and verification screens, -and a full admin dashboard with tabs for users, analytics, -security, and settings. - -The architecture uses Clean Architecture with MVVM pattern, -Koin for dependency injection, and Ktor for HTTP communication. - -We achieve 90 percent code sharing across platforms through the -shared module, which contains 10 use cases, 5 view models, and -all API contracts. Production API URLs are configured and ready -for integration testing. -``` - ---- - -## SLIDE 13: NFC Document Verification (45 sec) - -``` -We built two NFC reader implementations. - -The Universal NFC Reader supports over 10 card types — Turkish -national ID cards, e-Passports, Istanbulkart transit cards, -various MIFARE cards, and generic NFC tags. - -For identity documents, we implement BAC authentication using -MRZ data, then read personal data from DG1 and extract the -photo from DG2 in JPEG2000 format. - -Security features include PIN and password memory-only handling, -two-phase memory wipe, 3DES encryption for secure messaging, -and SOD signature validation using Bouncy Castle. - -The dedicated Turkish eID Reader is fully functional with -Material Design 3 UI and full compliance with ISO 14443 and -ICAO Document 9303 standards. -``` - ---- - -## SLIDE 14: Testing Strategy (50 sec) - -``` -Our testing strategy covers multiple layers. - -At the unit level, we have 508 tests for the identity core API -using JUnit 5 and Mockito. All 10 auth handlers have dedicated -test classes with over 30 test methods total. - -For integration testing, we use TestContainers with a real -PostgreSQL 16 database — because H2 cannot handle PostgreSQL- -specific types like text arrays and JSONB that our auth entities -use. - -End-to-end testing uses Playwright against our production -deployment. 14 tests pass covering login, users CRUD, auth flow -builder, and multi-step authentication. - -A key innovation in our E2E tests is the auth setup pattern. -We login once and save the session, then inject it into all -subsequent tests. This eliminates rate limiting issues that -caused failures when each test file logged in independently. -``` - ---- - -## SLIDE 15: Challenges (45 sec) - -``` -We encountered and solved several significant challenges. - -The H2 database limitation was the most impactful — our auth -entities use PostgreSQL-specific column types that H2 cannot -handle. TestContainers solved this by spinning up a real -PostgreSQL instance for each test run. - -Rate limiting in end-to-end tests was tricky — our production -API limits login attempts, and multiple test files each logging -in caused 429 errors. The auth setup pattern fixed this elegantly. - -The 4GB VRAM constraint on our GPU required careful model -selection. GhostFaceNet and RetinaFace are lightweight enough -to run face verification in 200 milliseconds while staying -under 2GB GPU memory. - -Virtual camera injection is a real threat for browser-based -face verification. Our mitigation is multi-factor authentication — -even if someone bypasses face detection, they still need -password or OTP verification. -``` - ---- - -## SLIDE 16: Lessons Learned (40 sec) - -``` -Several key lessons emerged from this project. - -Hexagonal architecture truly pays off. When we added Twilio SMS -integration, we wrote one new adapter class with zero changes -to the domain layer. - -The strategy pattern for auth handlers was the right choice. -Adding a new authentication method is one class and one enum value. - -Browser-side machine learning is viable for production use. -MediaPipe runs face detection at 30 frames per second entirely -in the browser. - -And multi-tenant design must be done from day one. Retrofitting -tenant isolation after the fact would have been extremely costly. -``` - ---- - -## SLIDE 17: Future Work (40 sec) - -``` -Looking ahead, several enhancements are planned. - -High priority items include full Cloudflare Tunnel deployment -for the biometric processor and mobile app integration testing. - -Medium priority includes activating the Twilio SMS gateway in -production and adding TOTP enrollment with QR codes in the -dashboard. - -For longer term, we want real-time admin notifications via -Server-Sent Events, advanced analytics with trend charts, -and full WebAuthn CBOR attestation for hardware keys. - -The project currently stands at approximately 98 percent -complete, with over 400 source files, 76 endpoints, 9 ML models, -10 auth methods, and 522 tests. -``` - ---- - -## SLIDE 18: Thank You & Q&A (25 sec) - -``` -Thank you for your attention. - -FIVUCSAS is a live, deployed system. You can access the web -dashboard, API documentation, and landing page at the URLs -shown on screen. - -We are happy to answer any questions. -```