# 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

```rust
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.