add schema to store national identity information for ~users

[chadwhitacre]

⬑ #3994
#4006 →

Alright, let's do this. The eating of an 🐘 begins with the first bite! 🍴

Punchlist

• require schema_version in info field
• add client-side encryption to info field(!)
• log events
• finish docs
• clean up commits

PRs

• identity preliminaries: identity preliminaries #4004 (against master), includes ...
  • fix the Makefile for sphinx: fix the Makefile for Sphinx #3996 (against master)
  • make way for refactoring participant: make way for refactoring participant #3997 (against master)
  • document add_event
  • prune dead crypto code
• add new crypto code: implement symmetric encryption #3998 (against master)
• add schema, data, and Python for countries: add schema and Python for countries #3999 (against implement symmetric encryption #3998)
• add schema and Python for storing and retrieving identities: implement encrypted national identities #4000 (against add schema and Python for countries #3999)
• add Python for verifying and unverifying identities: add schema and Python for [un]verifying identities #4001 (against implement encrypted national identities #4000)
• add Python for clearing an identity: implement clearing identities #4002 (against add schema and Python for [un]verifying identities #4001)
• add schema and trigger for participants.has_verified_identity: implement has_verified_identity #4003 (against implement clearing identities #4002)

[chadwhitacre]

I'm thinking that we'll use client-side encryption on the participant_identities.info field.

At this point we know very little about what exactly we'll need to collect. It may vary from country to country, and I suspect it'll be driven largely by the third-party verification vendor(s) we end up going with. Going with a JSON field for now seemed like the easiest way to get started.

I think we should allow multiple identities per ~user, but only one per ~user per country (we should account for dual citizenship, in other words).

I guess let's log changes to the events table, with the old info in the payload as with ... wherever else it was that we did that recently. :-)

[chadwhitacre]

I'm expecting that eventually we'll add a team_identities table that links with teams.

[chadwhitacre]

At a minimum, the bank must obtain the following identifying information from each customer before opening the account:

• Name.
• Date of birth for individuals.
• Address.
• Identification number.

#3289 (comment)

[chadwhitacre]

Turns out we have an identity form still hanging around post-Balanced.

[mattbk]

I guess let's log changes to the events table, with the old info in the payload as with ... wherever else it was that we did that recently. :-)

#3923 (comment)

[aandis]

geez. Why not a single multi row INSERT statement?

[chadwhitacre]

Laziness, sorry. Cleaned up in d78a132. 😊

[chadwhitacre]

Rebased on master at 4270aa0. Previous head was 1b97231.

[chadwhitacre]

Lotta discussion over here. A summary:

• Individuals can renounce their citizenship. We should allow ~users to deactivate the national identities they have stored with us.
• Countries fork and merge. This would be a case of mass deactivation and reregistration.
• Deactivating one's last participant_identities should a) either remove you from all Teams, or b) be prevented if you're still on a Team. Probably the former?
• Our recent pattern has been to include old info in the events table when we log changes. However, we want to keep PII in one place; we don't want to also store it in the events table. What we're thinking is that we'll use our old ctime/mtime pattern (a la payment_instructions)—still also logging to events, but with the ids of the old and new records rather than the full info.
• We don't want to overengineer the info schema right now. We'll collect (add schema to store national identity information for ~users #3976 (comment)) name, address, date of birth, and identity number (allowing for national id, drivers license, and/or passport). We should version the schema so we're in a better position as we need to start validating it more strictly.

[chadwhitacre]

MIT flags: https://www.gosquared.com/resources/flag-icons/

[kaguillera]

Sprite/css flags alternative as discussed
https://www.flag-sprites.com/

[kaguillera]

CSS: (https://gist.github.com/kaguillera/267ee747bd1e7679732b81d7b2f78d10)

Sample code for Czech Republic flag
<img src="blank.gif" class="flag flag-cz" alt="Czech Republic" />

[chadwhitacre]

I'm now questioning why we need to retain old PII. Seems safer to simply delete or overwrite it as requested.

[chadwhitacre]

More like a2c1d31 (previous was fd6d635).

[chadwhitacre]

[chadwhitacre]

Okay! Got a good chunk of work done here. I am ruminating on how to carve this up into easily reviewable PRs ...

[chadwhitacre]

I thought we already had participants.has_verified_email

It's not a boolean, it's the address itself: participants.email_address.

[chadwhitacre]

Old head was 9907401.