quicproquo/docs/specs/fapp-security.md

FAPP Security Model — Protecting Patients from Fraud

Threat Model

Who are we protecting?

Patients seeking psychotherapy are in a vulnerable state. They may be:

• Desperate after months of searching
• Unfamiliar with the healthcare system
• Willing to pay out-of-pocket if GKV slots are scarce
• Trusting of anyone who appears professional

What are the threats?

Threat	Description	Severity
Fake Therapist	Attacker poses as licensed therapist, collects patient data	CRITICAL
Phishing	Fake slots lead to malicious contact forms	HIGH
Financial Fraud	"Therapist" demands upfront payment	HIGH
Data Harvesting	Collect patient health queries for profiling	MEDIUM
Spam Flooding	Overwhelm mesh with fake announces	MEDIUM
Impersonation	Clone a real therapist's identity	CRITICAL

Current Protections (v1)

Protection	Mechanism	Weakness
Approbation Hash	SHA-256 of credential number	Cannot be verified — attacker can invent hash
Ed25519 Signature	Proves control of mesh key	Doesn't prove real-world identity
Sequence Dedup	Prevents replay	Doesn't prevent new fake announces
Rate Limiting	Max announces/hour	Attacker can use multiple keys

Honest assessment: Current protections prevent spam but do not prevent fraud.

Proposed Security Enhancements

Level 1: Transparency (Low Trust, No Verification)

Concept: Make it easy for patients to verify therapists themselves.

1. Therapist Profile URL

   • SlotAnnounce includes optional profile_url: String
   • Points to therapist's website, Jameda profile, or KV listing
   • Patient can cross-check before booking

2. Approbation Display

   • Show first 4 digits of Approbation hash in UI
   • Patient can ask therapist to confirm during Erstgespräch
   • Social verification, not cryptographic

3. Warning Labels

   • UI shows "Unverified Therapist" prominently
   • Patient must acknowledge risk before reserving

Implementation: ~2 days, no infrastructure changes.

Level 2: Web-of-Trust (Medium Trust)

Concept: Trusted nodes vouch for therapists.

1. Endorsement Messages

   • Trusted relays (e.g., run by patient advocacy groups) sign endorsements
   • TherapistEndorsement { therapist_address, endorser_signature, reason }
   • Patients can filter by "endorsed by [Patientenberatung]"

2. Reputation Scores

   • After appointments, patients can rate (anonymously)
   • Aggregate scores propagate through mesh
   • New therapists start with "No ratings yet"

3. Blocklists

   • Community-maintained blocklists of known fraudsters
   • Relay nodes can subscribe and filter

Implementation: ~2 weeks, requires gossip protocol for endorsements.

Level 3: Registry Integration (High Trust)

Concept: Verify against official sources.

1. KV-Registry Lookup

   • Germany: KBV Arztsuche API (https://www.kbv.de/html/arztsuche.php)
   • Therapist provides Lebenslange Arztnummer (LANR) or BSNR
   • Gateway node queries registry, signs attestation

2. eHBA Integration (long-term)

   • Electronic Health Professional Card
   • Therapist proves identity via qualified electronic signature
   • Strongest guarantee, but requires card reader

3. Chamber Verification

   • Psychotherapeutenkammer publishes member lists
   • Automated scraping + attestation (legally gray)

Implementation: 1-2 months, requires trusted gateway infrastructure.

Recommended Roadmap

Phase 1: Ship with Warnings (Now)

┌─────────────────────────────────────────────────┐
│  ⚠️  UNVERIFIED THERAPIST                       │
│                                                 │
│  This therapist has not been verified.          │
│  Before booking:                                │
│  • Check their website or Jameda profile        │
│  • Verify Approbation during first contact      │
│  • Never pay upfront without meeting            │
│                                                 │
│  [I understand the risks] [Cancel]              │
└─────────────────────────────────────────────────┘

• Add profile_url field to SlotAnnounce
• Prominent warnings in UI
• Educational content about verification

Phase 2: Endorsements (Q2 2026)

• Partner with 2-3 patient advocacy groups
• They run relay nodes with endorsement capability
• "Endorsed by Unabhängige Patientenberatung" badge

Phase 3: Registry (Q4 2026)

• Build KBV gateway (if API access granted)
• Or: manual verification service (humans check credentials)
• Verified badge with expiry

Technical Implementation

SlotAnnounce v2

pub struct SlotAnnounce {
    // ... existing fields ...
    
    /// Optional URL to therapist's public profile (Jameda, website, KV listing).
    pub profile_url: Option<String>,
    
    /// Optional LANR (Lebenslange Arztnummer) for registry lookup.
    pub lanr: Option<String>,
    
    /// Verification level (0 = none, 1 = endorsed, 2 = registry-verified).
    pub verification_level: u8,
    
    /// Endorsement signatures from trusted nodes.
    pub endorsements: Vec<Endorsement>,
}

pub struct Endorsement {
    /// Address of the endorsing node.
    pub endorser_address: [u8; 16],
    /// Ed25519 signature over (therapist_address, timestamp).
    pub signature: [u8; 64],
    /// Unix timestamp of endorsement.
    pub timestamp: u64,
    /// Human-readable reason.
    pub reason: String,
}

Patient-Side Verification Flow

1. Patient receives SlotAnnounce
2. UI shows verification_level:
   - 0: "⚠️ Unverified" (red)
   - 1: "✓ Endorsed by [name]" (yellow)
   - 2: "✓✓ Registry Verified" (green)
3. Patient can click to see:
   - Profile URL
   - Endorsement details
   - Verification expiry
4. Before SlotReserve, patient confirms risk acknowledgment

What We Cannot Prevent

Even with Level 3 verification:

1. Licensed but Unethical Therapist — Credential is real, behavior is not
2. Session Quality — Verification proves license, not competence
3. Availability Lies — Therapist might not actually have slots
4. Price Gouging — "Selbstzahler" with inflated rates

These require reputation systems and patient reviews — can't be solved cryptographically.

Comparison to Existing Systems

System	Verification	Privacy	Decentralized
Doctolib	KV registry	Low (tracks searches)	No
Jameda	None (self-reported)	Low	No
KBV Arztsuche	Official	Medium	No
FAPP v1	None	High	Yes
FAPP + Level 2	Endorsements	High	Yes
FAPP + Level 3	Registry	High	Mostly

Conclusion

FAPP's strength is patient privacy. We should not sacrifice that for centralized verification.

Recommended approach:

1. Ship with strong warnings and profile URLs (transparency)
2. Build endorsement network (web-of-trust)
3. Add optional registry verification for therapists who want it
4. Let patients choose their trust level

The mesh provides the infrastructure. Trust is a social problem that requires social solutions.