# Security Considerations

## Privacy Assumptions

Self Connect's privacy model assumes:

1. **ODIS Operators:** At least k operators remain honest
2. **Rate Limiting:** Quota system prevents mass scraping
3. **Blinding:** Client-side blinding is implemented correctly
4. **No Collusion:** Attackers don't control k or more ODIS operators

**If Assumptions Hold:**

* Identifiers cannot be reverse-engineered from blockchain data
* Rainbow table attacks are prohibitively expensive
* User privacy is preserved

**If Assumptions Fail:**

* If k operators are compromised: Peppers for any identifier can be computed
* If rate limiting is bypassed: Rainbow tables become feasible

## Sybil Resistance

Self Connect provides Sybil resistance through:

1. **Verification Requirements:** Users must prove ownership of identifiers
2. **Issuer Quality:** Applications choose issuers with strong verification
3. **Costly Registration:** ODIS quota costs make mass fake registrations expensive
4. **Unique Identifiers:** Phone numbers and verified social accounts are limited per person

**Limitations:**

* Relies on issuer verification quality
* Some identifiers (email) are easier to create in bulk
* Applications must choose issuers carefully

## Comparison: ASv1 vs. Self Connect

| Aspect                    | ASv1                              | Self Connect                 |
| ------------------------- | --------------------------------- | ---------------------------- |
| **Verification**          | 3 randomly selected validators    | Issuer (flexible method)     |
| **Trust Model**           | Single root: Validator collective | Multiple roots: Each issuer  |
| **Verification Quality**  | Standardized across network       | Varies by issuer             |
| **Flexibility**           | Phone numbers only                | Any identifier type          |
| **Censorship Resistance** | Validator majority                | Multi-issuer selection       |
| **Scalability**           | Limited by validator overhead     | Scales with issuer ecosystem |

## Best Practices

1. **Choose Trusted Issuers**
   * Evaluate verification methods
   * Check issuer reputation
   * Monitor issuer behavior
2. **Implement Rate Limiting**
   * Limit lookup frequency per user
   * Monitor for abnormal query patterns
3. **Validate Results**
   * Check timestamps for recency
   * Verify issuer addresses
   * Handle multiple attestations appropriately
4. **Secure Key Management**
   * Protect issuer private keys
   * Use hardware security modules for production
   * Implement key rotation procedures
5. **Monitor ODIS Quota**
   * Set up alerts for low quota
   * Implement automatic top-ups
   * Track quota usage patterns