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

One of the big benefits of Nametag is that you don’t need to store any personally identifiable information. You can, of course, and Nametag can even help you with that, but you can store literally NO PII and still be able to do all of the user account management, reporting on users, marketing research, and everything else you need to do 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 Login

  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 and then looks in the user database, comparing hashed values or, if the user doesn’t have an account, one is created for them, using hashed email and password. NOTE: At this point, your database looks like this and contains no personally identifiable information

    id email password
    1 ce15aff7[…] 46a9d5bd[…]

  4. The user is directed to the Nametag login page, where they enter their phone number or Nametag ID number. They are then alerted by the app on their mobile phone that you would like them to share their email address, name, and postal address. If they approve, your web application will get back a Nametag Subject, which looks like 7yrxpm0oy4l7iycrrkEs5mpwwi@yujstm3v0ljqsx.nametag.co and which should also be stored in your database. Now your database still has no PII in it and looks like this

    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 on your website expires, they log out, or is otherwise ended, you are left with no PII for that user, and three irreversibly hashed pieces of information.

Returning Login

  1. When the user returns and logs in again, the first three steps from the Initial Login 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 nametag_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 login 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 nametag_subject for the matching accounts

From that list of nametag_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 login 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 US 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, since there is no PII in that.