Interview: Andrew Fitz Gibbon

# Discussion
Key: Keep the users' data on their sides.

## Scenario 1: Direct verification of SSN
1. A customer reserves a room in a hotel.
2. The hotel requests for the their SSN.
3. The hotel sends the SSN to the government for verification.

### Problem: Risky to give out SSN
| Untrusted | Trusted | Untrusted |
|-|-|-|
| Hacker | Customers <-> government | Merchant |
* Sensative data stored by the merchants may be abused or hacked.
* Since customers do not trust merchants, the real SSN should be directly verified rather than handed over by the merchants.

### Analogy: Credit card / mobile pay
* Key Generate tokens
* Problem: The merchants hold the credit card information, which is risky (similar to the aforementioned reasons for user data)
* Solution: Mobile payment e.g. Apple Pay: Somehow trusted

### Solution applied on the SSN case

# Conclusion
Keep all data and purchase history on users' sides.
Third-party recommendation system (or run it locally) to process those.

# Questions raised
No motivation for the merchants (pay for service; can't hold the data as they do now) & customers (satisfied with current services; prefer convenience over security)

# Resources
* No expert's export :(
* Password management company /open sources projects
* Data security
* RSA (company)
* Journal/conference: InfoSec, [DevCon](https://devcon.org)