What is Identity?
Identity connects a person or thing with the information a system holds about it. Understanding that relationship is the starting point for deciding what to trust and what access to allow.
Identity in context
Identity helps us answer a basic question: who or what are we dealing with? In everyday life, the answer depends on context. You might be a customer, an employee, a student, or an account holder. You are the same person, but each relationship involves different information, expectations, and permissions.
You open your photo account and see your name beside an album. At work, the same name appears in an employee directory. Both records concern you, but they exist for different reasons. The photo service needs to connect you with your photos; your employer needs to connect you with your work.
Being a customer of one service does not make you an employee of another, even when both records carry the same name. The identity a system works with belongs to that relationship.
Photo service
- Relationship
- Album owner
- Name
- Your name beside an album
- Exists to
- Connect you with your photos
Work directory
- Relationship
- Employee
- Name
- The same name
- Exists to
- Connect you with your work
Being a customer of one service does not make you an employee of another, even when both records carry the same name.
Digital representations
Think of the photo account as a record the service can work with. It might hold a user ID, a name, an email address and an account status. The person it represents is the subject. Information describing that subject is held as attributes, while an identifier distinguishes the record within the system.
Suppose you change your name. The service should still recognize the account and keep your albums connected to it. A stable user ID lets it follow the record while descriptive fields change. A display name is useful to people, but two matching names don't establish one account or one person.
The distinction between a subject and its digital representation matters. You are not your account. Your account represents you within a particular system, and you may have many accounts across different systems. An email address can help identify an account. A password, or a small device made for signing in, can help prove control of it. Neither, by itself, describes everything about who you are.
Software needs records too. A printing application, a device or an automated service can have a digital identity. Its identifier lets another system distinguish it from the other applications or devices making requests.
Before
- Name
- an old display name
- Account
- photo-42
After
- Name
- a new display name
- Account
- photo-42
Identity and Access Management
Once the service has these records, someone has to look after them. New accounts are created, details change, access is granted or removed, and accounts eventually close. Identity and access management, usually shortened to IAM, covers that work along with authentication, which checks that the person signing in controls the account, and access decisions and their enforcement.
Many organizations give much of this work to a dedicated identity service. It keeps the accounts, runs sign-in and answers access questions for the applications that rely on it, so each application doesn't have to build all of that itself. One identity service can also host many organizations at once. Each organization then has its own separate space, called a tenant, with accounts, applications and settings that other tenants can't see or change.
Imagine a photographer joining a team and later leaving it. The service needs to create the right account, provide a way to sign in, allow the team's work and remove that access when it is no longer appropriate. These decisions are connected, but they answer different questions.
Understanding identity means understanding those connections: the person or thing being represented, the information a system holds about it, the evidence that supports trust, and the access that follows.
Joining a team
- Account
- Create the right account and provide a way to sign in
- Access
- Allow the team's work
Working
- Account
- Details change
- Access
- Granted or removed
Leaving it
- Account
- Accounts eventually close
- Access
- Remove that access when it is no longer appropriate
These decisions are connected, but they answer different questions.
Claims and evidence
Before relying on a record, ask where its information came from. If you type a name and job title into a form, the service now holds those values. Saving them hasn't established that they're true. Each is a claim, a statement about the subject.
A nickname beside a photograph may need no checking. A claim that someone manages a team matters more if it would let them approve other people's access. The service needs evidence appropriate to that decision, such as confirmation from the employment system responsible for the role.
The same care applies to sign-in. Knowing a password may demonstrate control of an account without establishing the person's legal name. An email code may demonstrate access to a mailbox without verifying a job title.
Profile formSaving them hasn't established that they're true. Each is a claim, a statement about the subject.
A nickname beside a photograph
- Claim
- A nickname
- Could let them
- Appear beside a photograph
- Evidence
- May need no checking
"I manage this team."
- Claim
- Manages a team
- Could let them
- Approve other people's access
- Evidence
- Confirmation from the employment system responsible for the role
Knowing a password may demonstrate control of an account without establishing the person's legal name.
Check your understanding
Try these questions before moving on. If an answer isn't right, use the feedback and try again.
Try it in the Lab
- Get to know Ava through her accountFollow one account from its record through a name change, and see what the system knows about the person using it.