How to store no personally identifiable information and still run a business

One of the biggest benefits of Nametag is that you don’t need to store any personally identifiable information. You can store literally no PII and still handle user account management, reporting, marketing research, and everything else you need to run your business.

Let’s say you need to support the following:

• users logging into your website using their email address and a password for your site.
• displaying the full name and email address of the users when they are logged in to your website.
• sending emails to past customers with information that pertains to their last purchase.
• assembling marketing and sales reports based on US states.

The information you need for each person is then:

• email address.
• password.
• full name.
• address (or, at least, the state they live in).

Nametag can provide all except the password.

You need to store:

• one-way hash of the email address.
• one-way hash of the password.
• Nametag subject.

In combination with your Nametag API credentials, you can build the following flows:

Initial sign in

1. User enters email address and password on website

2. Email address and password are encrypted by the browser using TLS and sent to the web server.

3. The web application hashes both the email address and password, then looks up the user by comparing hashed values. If the user doesn’t have an account, one is created with the hashed email and password. Note: At this point, your database contains no personally identifiable information:

   id	email	password
   1	ce15aff7	46a9d5bd

4. The user is directed to the Nametag sign-in page, where they verify their identity. If they approve sharing their email, name, and postal address, your app receives a Nametag Subject (e.g. 7yrxpm0oy4l7iycrrkEs5mpwwi@yujstm3v0ljqsx.nametag.co), which you store in your database. Your database still contains no PII:

   id	email	password	nametag_subject
   1	ce15aff7	46a9d5bd	7y@yuj.nametag.co

   At this moment, your web application also has access the user’s full name, email address, and mailing address from the Nametag API. It can use this access to display information, customize content, etc.

5. When the user’s session expires, they log out, or their session otherwise ends, you’re left with no PII – just three irreversibly hashed values.

Returning sign in

1. When the user returns and signs in again, the first three steps from the initial sign in flow are the same, but instead of re-directing the user to the Nametag site, you can use your company’s Nametag credentials and the stored subject to retrieve the user’s information.

   If the user has revoked the permission they granted you or the permission has expired, you can direct them to the Nametag sign in page again, or handle it in your app in another way.

Sending emails to customers

When the marketing department wants to send email to customers, they can construct the list of people they want to reach based on whatever criteria they want (people who purchased a Type 42 Widget, people who logged in last Tuesday, etc) and collect from that the subject for the matching accounts

From that list of subject strings and your company’s Nametag credentials, you can ask Nametag for the email addresses for all of those subjects.

Some of the customers in that list may have revoked your access to their email address, effectively removing them from your mailing list. This will also have the effect of (optionally) redirecting them to Nametag to re-authorize you to see their information on their next sign in to your website

When the mailing campaign is done, you can remove the email addresses from your systems, returning to the state of not holding any PII about your customers.

Reports by state

This is the same process as sending emails to customers, just asking for the address information instead of email addresses, although in this case you could keep the aggregated information about states, because there is no PII in that.