What is digital identity?

A teller who doesn’t check

Picture yourself walking into your bank branch on a Monday at ten in the morning. The teller doesn’t recognize you, your name doesn’t appear on her screen, and she still hands you 500 dollars in cash because you said it was you. It sounds absurd. Yet that exact scene, moved into the digital world, happens every day in badly designed applications: someone types an email and a password, and the system trusts them without checking anything else.

Digital identity is what keeps that from happening. Every security decision, what you can see, what you can change, what you can pay, is made on top of an identity. If that foundation is weak, everything built on it is weak too. That’s why a concept that looks introductory is in fact the most important one in the whole program.

This article covers three things that everything else rests on. First, what a digital identity actually is. Then the difference between four words people often use as if they meant the same thing: subject, identity, account and profile. And finally the pieces that make an identity work in practice: attributes, claims, entitlements and credentials. Modern identity types, people, devices, workloads and AI agents, and the idea of identity as the “new perimeter” get their own article, the next one in this block.

What a digital identity really is

The formal definition comes from NIST SP 800-63: a digital identity is the unique representation of a subject in an online transaction.

It sounds more complicated than it is. Put simply, a digital identity is what a system knows about you so it can decide what to do when you interact with it. It’s like your file at the doctor’s office, except it lives in a database instead of a filing cabinet.

Think about your identity in the physical world. You have an ID card with your photo, your name and your date of birth. You have a passport that also carries stamps from the countries you’ve visited. You have a driver’s license that says which vehicles you may drive, and a credit card that shows a bank trusts you up to a certain limit. All of those documents represent the same person, you, but each one identifies you for a different purpose. None of them is you; each is a valid representation of you in a particular context. And nobody hands you an ID card until you’ve proved who you are, usually with another document or your fingerprint at the registry office.

Digital identity works the same way, except the documents live in databases and the proofs travel over encrypted connections. Your identity at a fintech app is like your ID card inside that fintech’s system. Your identity in your work email is like your employee badge. Your identity at a streaming service is like a membership card. They all represent the same person, but each one lives in its own world.

Four ideas are packed into that definition. A digital identity is a representation, not the person: you’re a person, and your identity is what the system knows about you. It’s unique within a context: your identity at your bank is unique there, and so is your identity at a streaming service, but they’re two different identities that happen to point at the same person. It’s practical: it exists so a system can make decisions, like whether this user can read this file or whether this payment should go through. And it comes with attributes, credentials and entitlements; without those, an identity would be an empty label.

One way to picture all this is as a tree with four branches. The root is the identity, and each branch holds a different kind of information: the data that describes you, the proof that you are you, what you’re allowed to do and the moment in which you’re acting.

Here’s what that looks like in real life. When Sara opens an account with a fintech app, her digital identity starts to exist at that moment. The fintech doesn’t have her face, her birth certificate or her physical ID card. What it has is an email and a phone number it verified, a password she chose, a PIN or a fingerprint she registered for payments, a photo of her ID card that went through an identity-proofing check, an account level, basic or premium, that limits what she can do, and over time a history of logins from her usual phone. That combination is Sara’s digital identity at the fintech. It’s different from her identity at her bank, at a food-delivery app or at a streaming service, even though all of them represent the same Sara.

Subject, identity, account and profile

In one sentence: the subject is the real thing, the identity is how one system represents it, the account is the technical record where that identity is stored, and the profile is a partial view of the identity shown in a particular context.

These four words often get used as synonyms. They aren’t, and mixing them up is behind some of the most common design mistakes in IAM projects.

Subject

The subject is the real entity, the thing that exists in the world and that the digital identity represents. It can be a person, Sara López, 32, living in San Salvador. It can be a device, an iPhone with serial number ABC123. It can be a service, the billing microservice running in Kubernetes. Or it can be an AI agent, the bot that schedules meetings in your calendar. The subject lives outside the digital system; it’s what the system is talking about. A person can have many digital identities, one per system, and still be a single subject.

Identity

The identity is the digital representation of the subject in a specific context. Each time a subject signs up for a system, a new identity is born. Sara has an identity at her bank, another at her fintech app, another in her work email and another at a streaming service. All four have the same subject behind them, but they’re four different identities, each with its own attributes, credentials and entitlements.

A good test of whether the difference has sunk in: if Sara changes her surname when she marries, her subject doesn’t change, she’s the same person, but each of her identities has to update its surname separately, system by system. That’s the clearest sign that subject and identity are different things. One is the person; the other is what each system knows about the person.

Account

The account is the technical implementation of an identity inside a specific application. “Identity” is a concept; “account” is the row in the system’s database, with a username, a password hash, permissions and audit columns.

One identity can have several accounts. Sara’s work identity might have an account in the company directory, one in the CRM, one in the chat tool and one in the code repository, all belonging to the same identity. The distinction matters a great deal in identity governance, where orphan accounts are accounts whose identity no longer exists, typically because someone left the company and nobody removed their access to some application.

Profile

The profile is a partial view of an identity that depends on context. It’s what a system chooses to show at a given moment. Your public profile on a professional network is different from the private view only you see, and both are different from what paying recruiters see.

A profile does two jobs. It’s presentation, how you look to others, and it’s data minimization, how many attributes get exposed in each interaction. A good design never shows the world more than it needs to: not your date of birth to the cashier, not your salary to the marketing CRM.

Sara, from start to finish

Sara is a sociologist, lives in Santa Tecla and is 32. That’s the person, the subject. She downloads her fintech app, and as soon as she confirms her email and her ID card, the identity “Sara at the fintech” is born. It has attributes (name, date of birth, phone), credentials (password, PIN, fingerprint) and entitlements (basic customer, can transfer up to $500 a day).

In the fintech’s database that identity turns into three accounts: a row in customers with her personal data, a row in auth_credentials with her credentials and a row in wallet_accounts with her balance and transactions. When Sara opens the app, she sees her own profile: balance, recent transactions, her name. When another user wants to send her money and finds her in the search, they see a much smaller public profile, just her name and her photo.

One subject, one identity, three accounts, two profiles.

Daniel shows the same thing from a different angle. He owns a small electronics shop in San Miguel, and every morning he logs into three systems: a business chat app where he answers customers, an inventory system where he records incoming stock, and a business account at an online payment processor that handles card payments. The subject is one, Daniel. The identities are three, one per system. Each has its own technical accounts; the chat app might have one per business number, and the payment processor might separate “merchant” from “billing”. The profiles change with who’s looking. Customers see his photo and opening hours in the chat app, the tax authority would see his tax details if it audited him, and suppliers see his credit limit.

The interesting question for IAM is what happens when Daniel changes his phone number. Does it update in all three systems on its own? Almost never. Keeping all of that in step is exactly the job IAM exists to do.

The pieces: attributes, claims, entitlements and credentials

An identity that actually does something is made of four pieces: attributes, facts about it; credentials, what it uses to prove itself; entitlements, what it’s allowed to do; and claims, signed statements that carry attributes from one system to another. These four are the everyday vocabulary of IAM, the words you’ll hear constantly if you work in this field.

Attributes

Attributes are facts about the identity. If you’ve ever filled in a sign-up form, you already know what they are: every field was an attribute. Some never change, like a date of birth. Some change slowly, like a surname or a department. Some change all the time, like current location or the device in use. Typical examples are first and last name, email and phone, date of birth, ID or tax number, department, manager and office, preferred language and the date of the last login.

Attributes live in an identity store, Active Directory, LDAP or the application’s own user database, and applications read them to make decisions or to personalize what you see. When you design a system, it’s worth asking three questions about every attribute: who writes it, who updates it and who reads it. Most out-of-date data in an organization comes from nobody having answered them.

Claims

A claim is a digitally signed statement that an issuer makes about an identity, addressed to someone who will receive it. The key word is signed: a claim can be trusted because it carries the issuer’s cryptographic signature.

Think of a friend you both know telling you “this person is trustworthy; I lent them money and they paid it back.” You believe it not because you like the person, but because someone you trust is vouching for them. A claim works the same way. If Google signs “this email belongs to Sara”, the receiving app trusts it because Google’s signature is very hard to forge and Google is already on its list of trusted sources.

When you sign in to another app with your Google account, what the app receives is a set of claims signed by Google, something like this:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890abcdef",
  "email": "sara@gmail.com",
  "email_verified": true,
  "name": "Sara López",
  "iat": 1714579200,
  "exp": 1714582800
}

iss is the issuer, Google here. sub is Sara’s unique identifier inside Google. email_verified: true is the claim the app really wanted, confirmation that the email truly belongs to her. iat and exp are when the token was issued and when it expires. The app doesn’t need to ask Google whether the email is really Sara’s; Google’s signature on the token, a JWT, is enough.

So an attribute and a claim aren’t the same thing. An attribute is a piece of data that lives in a directory. A claim is that piece of data plus an issuer who backs it with a signature, and it travels inside a token, a JWT or a SAML assertion.

Entitlements

Entitlements describe what the identity is allowed to do. If credentials are the key that opens the door, entitlements decide what you can do once you’re inside: every room or only the hall, move the furniture or only look at it. Depending on the system they’re called different things. On Linux they’re rwx permissions and the sudoers file. In AWS they’re policies and roles. In Active Directory they’re memberships of security groups. In OAuth 2.0 they’re scopes. In a business application they’re roles like admin, editor or viewer. In a relationship-based model they’re relationships, “is a member of” or “owns”.

One thing to keep in mind from the start: entitlements aren’t checked when you sign in, they’re checked every time you try to do something. You sign in once a day; your entitlements are checked every time you press a button. The authorization models later in the program go much deeper into this.

Credentials

Credentials are what the identity presents to prove it is who it says it is. They’re the keys to the door. Some keys are cheap and easy to copy, like a password on a sticky note; others are expensive and very hard to duplicate, like your fingerprint or a hardware key such as a YubiKey. The more valuable whatever is behind the door, the stronger the key should be. Credentials are grouped by the kind of factor they rely on:

Modern credentials can be asymmetric, a pair of public and private keys as in FIDO2/WebAuthn, instead of a shared secret like a password. The difference matters. With a password, you and the server know the same secret, so if the server leaks it, your identity is exposed everywhere you reused that password. With an asymmetric credential like a passkey, the private key never leaves your device and the server only keeps the public key, which on its own is useless for signing in. That almost entirely removes phishing from the picture. A passkey, in plain terms, is a cryptographic key that lives in your phone or laptop and unlocks with your fingerprint or face; the server never sees it, it only receives proof that you used it. It’s the best credential available to ordinary users today.

How the pieces fit together

So far each piece has appeared on its own. Here they are together. On the left is a real-world subject; in the middle, a digital identity built from attributes and credentials, and two gates, authentication and authorization; on the right, an action that either runs or is blocked. A signed token carries the identity’s claims across the boundary, and entitlements decide what happens once inside.

That’s the teller from the beginning, done properly: she checks who you are before anything else, and then checks what you’re allowed to do before handing over a single dollar.

Recap

A subject lives in the real world: you, your phone, a microservice. Each subject can have several digital identities, one for each system it exists in, and each identity takes shape as one or more accounts in real databases. Identities show different profiles depending on who’s looking. What makes an identity useful is its attributes, what’s known about it; its credentials, how it proves itself; its entitlements, what it can do; and its context, where it’s acting from right now. When an identity signs in, an identity provider issues signed claims about it, and each time it tries to do something, its entitlements are checked against a policy. With that vocabulary you can follow a conversation with anyone who works in IAM.

Test yourself

1. Sara uses an app to order food. Name the subject, the identity, two possible accounts and two profiles the system might show.
2. Your team is building an internal tool where employees approve expenses. What would the key attributes of each identity be, which entitlements would you tell apart, and which credentials would you recommend?
3. If an app receives a JWT signed by an identity provider it doesn’t trust, what should it do, and why?