What exactly is a 'user account'?

Identity and Access Management might sound like technical jargon, but in reality, it plays a crucial role in everyone’s life. It encompasses how you present yourself online, how you protect yourself from online threats such as hacking and phishing, and how much control you have over your personal information. This post is the first of a series where I’ll delve into the complexities of identity and access management, and discuss its relevance to everyone.

The Concept of User Account

At the very heart of identity and access management lies the concept of a user account. In the context of the digital world, we can simply define a user account as something you log into to access your personal data or services. However, the concept of a user account predates computers and the digital era. And when we apply some of these pre-digital concepts to our modern digital environments, they can present certain challenges.

Understanding Identity Abstraction

In system and process development, a key technique we use is “abstraction”. The real world is a complex place, and when we’re designing a process or system, we don’t always want to deal with that complexity. So, we use abstractions of people, places, and things, including only the information that’s most relevant and important for a specific purpose. When it comes to an identity abstraction, this means we only need the information that’s relevant to the task at hand, or that will ensure we don’t get confused about who we’re talking about.

The Role of User Accounts in Record-Keeping

As societies evolved and civilizations formed, it became increasingly important to keep records about individuals. We needed a way to identify who we were talking about and to keep the necessary details about interactions we had with that person. This record-keeping could be relatively simple. For example, let’s say a neighbor borrowed a book from you. You would want to record some information about which neighbor and which book. The identity information you record wouldn’t include everything there is to know about the person, but it would include enough information for your record-keeping needs.

If this neighbor borrowed several books, you wouldn’t write down all the identity information next to each book title. Instead, you would probably just jot down the person’s first name next to the book titles, and store the more comprehensive identity information about the person in a separate place, like your contacts list.

In my field, we use specific terminology to describe these concepts:

• Data Subject: This is the person we’re talking about. In our example, this would be the person who borrowed the book.
• Identity Representation: This is how the actual person (the Data Subject) is referred to in a process or system. In our example, this would be the entry in your contacts list that you made for the person.
• Attributes: This is information that describes the data subject, and is usually associated with the identity representation. In our example, attributes could include the person’s name, address, or phone number.
• Credentials: These are “statements” about the data subject that are linked to the identity representation. In our example, a credential could be “borrowed my book” or “has my book”.

Let’s take a closer look at each of these concepts as they are used within processes or systems.

Credentials

Credentials or “statements” are generally information that is stored about a person. Examples might be the school they’re enrolled in or the fact that they’re licensed to drive a car. Sometimes these credentials are issued to a person (like a driver’s license or diploma) so they can present them to someone else. Other times, these credentials or “statements” are stored as part of record keeping (for example, this person attended class today, or this person borrowed money).

It’s important to note that the data subject doesn’t necessarily have to know all of the credentials that have been stored about them. For instance, you may have noted that the neighbor who borrowed a book was wearing a cool pair of sunglasses that you think your sister would like as a gift. Your neighbor might not know that you stored this information as a credential in your records and linked to your identity representation (contact entry) for them.

Identity Representations

Identity representations usually contain some way to uniquely refer to the identity. We can call this item the “identifier”. In our book borrowing example, we chose to store the person’s first name next to the book’s name so we could easily identify who borrowed the book. However, if you know more than one person with that first name, the name alone wouldn’t be enough to definitively (uniquely) identify the person. Large systems and processes address this challenge by assigning a unique identifier to the identity representation.

Attributes about the data subject are usually stored along with the identifier. In our example, our attributes included the address and phone number. But they might also include a note that this person wears prescription glasses, an attribute that is related to the credential that they own some great sunglasses.

Identity Credential

Sometimes, those who create and manage identity representations will issue a special credential to the person being represented, the data subject. We’ll call this special credential an “identity credential”, and it sometimes can be a physical item, like an ID card. This identity credential provides an efficient way for the person to show the agency the agency’s representation of them. These identity credentials always include the identifier, and sometimes also include some of the identity attributes. This information helps to link the person to their identity representation through the identifier and helps someone use the attributes on the ID card to verify that the person providing the ID is, in fact, the data subject.

In our book borrowing example, let’s imagine that you didn’t just loan the book from your personal library, but instead ran a larger library and maybe had an employee or two to help you. Your employees might not know your neighbor or how to find the credentials that you have stored about them (for example, the list of borrowed books). You might give your neighbor an ID card that includes some of the identity attributes that you have, to help the employees link information to the right person.

So What’s the Problem?

For a long time, there wasn’t really a problem. Those storing the identity representation and credentials are doing so for themselves. And, the attributes they gathered were from direct interactions with the data subject. The challenges come when IDs, attributes, and credentials are used by others who normally wouldn’t be involved. We can refer to these as “third parties”.

Consider a driver’s license. The ID provided to the driver is an identity credential that includes a unique identifier (the license ID number) and some attributes (name, address, photo, date of birth, etc.). The fact that one has this ID also implies that the person also has a credential, that they hold a license to drive a vehicle. Since others trust the agency that issued the ID card, others may use the attributes listed on the ID for third-party purposes, for example, to ensure that you are old enough to purchase a restricted item or to verify your address. The data subject can not selectively share those attributes. If the license ID is used to verify an address, the date of birth is also shared.

In a physical world, this might be a nuisance, but the consequences are limited. Sure, the person who checked your ID to verify your address can also see your date of birth, but they probably didn’t write it down and store it for others to see or for other uses. And, it is unlikely that they would be able to pull together a list of everyone who showed an ID that was born in the same decade as you.

Digital Identity Representations: A Different Ball Game

However, digital ID checking is a different ball game. Once the data from an identity credential are shared, the receiver likely records all of the attributes found on the identity credential. Moreover, the digital receiver may also collect attributes and credentials about you from other sources and their own interactions with you. Some of these credentials are things that you know about, and others may just be things that they noticed about you that you may not know about and may not have verified as correct.

And, there is a marketplace for those collecting this information to sell what they have collected to others who may have collected other attributes and credentials about you. Combine that data collection with relatively inexpensive storage, and the data collected may span a lifetime of interactions and data sharing. It would be a daunting task to get these organizations to share with you the information they have stored about you. And even if you could, it would be nearly impossible to get information from that list removed, corrected, or no longer shared. Fortunately, regulations and norms are starting to put control of this information back into the hands of the data subjects. I’ll share more about this progress in a future post along with more about using digital identity credentials.