What is digital identity?

Why this concept matters more than it seems

Imagine walking into your bank branch on a Monday at 10 AM. The teller doesn’t recognize you, your name doesn’t show up on her screen, and yet she hands you 500 dollars in cash “because you said it was you.” It sounds absurd. But that exact scene, translated to the digital world, happens every day in poorly designed applications: someone types an email and a password, and a system trusts without verifying anything else.

Digital identity is the foundation that prevents that absurdity. Every security decision — what you can see, what you can modify, what you can pay — is made on top of an identity. If the foundation is weak, everything else is too. That’s why this concept, which seems introductory, is actually the most important one in the entire program.

In this guide we’ll walk through three blocks that lay the groundwork for everything else: the definition of digital identity itself, the difference (often confused) between subject, identity, account, and profile, and the components that make up an operational identity — attributes, claims, entitlements, and credentials. If you want to dive deeper afterward into modern identity types (people, devices, workloads, and AI agents) and why identity is today’s “new perimeter,” those topics live in the second article of this block.

Definition: what is a digital identity, really?

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

That sentence sounds more complicated than it is. Translate it like this: 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, but living inside a database instead of a filing cabinet.

A real-world analogy

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 additionally carries stamps from countries you’ve visited. You have a driver’s license that says what kinds of vehicles you can drive. You have a credit card that proves a bank trusts you up to a certain limit.

All those documents represent the same person — you — but each one identifies you for a different purpose. None of them is “you” as such: they’re valid representations of you in specific contexts. And nobody hands you the ID card unless you first prove you are who you say you are, generally with another document or with your fingerprint at the registry.

Digital identity works exactly the same way, except the documents live in databases and the proofs travel through encrypted channels. Your identity at NIU (a local fintech) is like your ID card inside the NIU system; your identity in your work email is like your employee badge; your identity in Spotify is like a membership card. They all represent the same subject, but each lives in its own universe.

The four ideas inside the definition

For the definition to be useful in practice, it helps to unpack it into four ideas:

1. It’s a representation, not the subject itself. You are a person; your digital identity is what the system knows about you.
2. It’s unique within a context. Your digital identity at your bank is unique; at Netflix, also — but they’re different identities that happen to represent the same person.
3. It’s operational, not contemplative. It exists to make decisions: can this user read this file? can this payment be executed?
4. It has attributes, credentials, and entitlements associated with it. Without those three pieces, an identity would be just an empty label.

The anatomy of a digital identity

To make it easier to visualize, think of a digital identity as a tree with four branches. The root is the identity, and each branch groups a different type of information. One branch for the data that describes you, another for the proofs that you are you, another for what you have permission to do, and another for the specific moment you’re acting in. Here’s the schematic:

flowchart TB
  accTitle: Anatomy of a digital identity
  accDescr: Tree diagram with the root Digital Identity branching into four groups (attributes, credentials, entitlements, context) each expanded with concrete examples.
  ID([Digital Identity])
  ID --> ATR[Attributes]
  ID --> CRED[Credentials]
  ID --> DER[Entitlements]
  ID --> CTX[Context]
  ATR --> A1[Name]
  ATR --> A2[Email]
  ATR --> A3[Department]
  CRED --> C1[Password]
  CRED --> C2[FIDO2 key]
  CRED --> C3[Certificate]
  DER --> D1[Roles]
  DER --> D2[Permissions]
  DER --> D3[Groups]
  CTX --> CT1[Device]
  CTX --> CT2[Location]
  CTX --> CT3[Time]

Quick read of the schematic: four arms. What the system knows about you (attributes), what you use to prove that you’re you (credentials), what the system lets you do (entitlements), and where you’re acting from right now (context). We’ll see each one in detail later, but hold on to this mental image — it’s the one we’ll be filling in throughout the article.

A concrete example: your identity at a fintech

When you open your account at a fintech like NIU or n1co (local Salvadoran cashback apps), your digital identity starts existing right then. The fintech doesn’t have your face, doesn’t have your birth certificate, doesn’t have your physical ID card. What it has is:

• An email and a phone number it verified (attributes)
• A password you established (credential)
• A PIN or biometric you registered for transactions (additional credentials)
• A photo of your ID card processed by an identity proofing system (verified attribute)
• An account level — basic, premium — that defines what you can do (entitlements)
• A history of logins from your usual phone (context that gets learned over time)

That combination is your digital identity at the fintech. It’s different from your digital identity at your bank, at Uber Eats, or at Netflix, even though they all represent the same person.

Subject, identity, account, and profile: four words that get confused

These four terms are sometimes used as synonyms. They’re not. Confusing them is the source of the most common architectural mistakes in IAM projects. Let’s go through them one by one, calmly.

Subject

The subject is the real entity, the thing that exists in the world that the digital identity represents. It can be:

• A physical person: María García, 32 years old, resident of San Salvador.
• A device: the iPhone 15 with serial number ABC123.
• A service: the billing microservice running in Kubernetes.
• An AI agent: the bot that schedules meetings on your calendar.

The subject lives outside the digital system. It’s the referent. A person can have many digital identities (one per system), but they remain a single subject.

Identity

The identity is the digital representation of the subject in a specific context. Every time a subject signs up to a system, a digital identity is born. María has an identity at her bank, another at NIU, another in her work email, another at Spotify. The four have the same subject behind them (María), but they’re four different identities, each with its own attributes, credentials, and entitlements.

A good way to test that you understand the difference: if María changes her last name when she gets married, her subject stays the same (she’s the same person), but each of her digital identities has to update the “last name” attribute separately, in each system. That tells you clearly 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 within a specific application or system. While “identity” is a concept, “account” is the row in the system’s database, with its username, password hash, permissions, and audit columns.

An identity can have several accounts: María’s identity at work might have an account in Active Directory, an account in Salesforce, an account in Slack, an account in GitHub. They’re all accounts of the same identity. This distinction is critical in IGA: “orphan accounts” are accounts whose identity no longer exists (typically because the person left the company but their access in some app was never removed).

Profile

The profile is a partial, contextual view of an identity. It’s what a system decides to show or expose at a given moment. Your public profile on LinkedIn is different from your private profile on LinkedIn (which only you see), and both are different from the profile that paying recruiters see.

The profile serves two purposes: presentation (how you look to others) and data minimization (how many attributes to expose in each interaction). Good architecture never shows the world more than necessary — neither your date of birth to the cashier, nor your salary to the marketing CRM.

Quick comparison table

Relationship diagram (UML class)

If it helps to see it in UML notation — those little boxes with properties you’ve probably already seen if you work with databases or object-oriented programming — the relationships between the four concepts look like this. The arrows read as “has” or “materializes as,” and the numbers (1, 0..*, 1..*) indicate how many elements on one side connect to the other. For example, 1 → 1..* means “one to one or more”:

classDiagram
  accTitle: Subject, Identity, Account, Profile relationships
  accDescr: UML class diagram with four boxes (Subject, Identity, Account, Profile) connected by arrows that read as has, materializes as, and projects as, with cardinalities like 1 to many.

  class Subject {
    +realName: String
    +entityType: String
    +dateOfBirth: DateTime
  }
  class Identity {
    +identityId: String
    +attributes: Attributes
    +credentials: List~Credential~
    +entitlements: List~Entitlement~
  }
  class Account {
    +accountId: String
    +username: String
    +system: String
    +status: String
  }
  class Profile {
    +useContext: String
    +visibleAttributes: Map
  }
  Subject "1" --> "1..*" Identity : has
  Identity "1" --> "0..*" Account : materializes as
  Identity "1" --> "0..*" Profile : projects as

María’s case, step by step

María is a sociologist, lives in Santa Tecla, and is 32 years old. That’s the person, the subject.

María downloads the NIU app. The moment she validates her email and her ID card, her digital identity “María at NIU” is born. That identity has attributes (name, date of birth, phone), credentials (password, PIN, biometric), and entitlements (basic-level customer, can transfer up to $500 per day).

In NIU’s database, this identity materializes as three different accounts:

• A row in customers (personal data)
• A row in auth_credentials (credentials)
• A row in wallet_accounts (her balance and movements)

When María enters the app, she sees her personal profile: balance, recent transactions, her name. When another user sends her money via P2P and María shows up in the search, what they see is a much more reduced public profile: only her name and her photo.

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

A second example to reinforce

So the idea sticks, let’s look at the case of Roberto, the owner of a small electronics shop in San Miguel. Roberto connects every morning to three different systems:

• His WhatsApp Business to attend to customers.
• His inventory system that he uses to record incoming merchandise.
• His business account at n1co to process card payments.

The subject is one: Roberto, a physical person with an ID card. The digital identities are three different ones, one per system. In each one there are technical accounts (in WhatsApp Business there are several, one per WhatsApp number; at n1co he could have separate accounts for “merchant” and “billing”). And the profiles change depending on who’s looking: his customers see a public profile on WhatsApp with his photo and hours; the tax authority — if it audits — would see a profile with his tax data; his suppliers see one with his credit limit.

The same Roberto, but seen through four different lenses. The interesting question for IAM is: what happens if Roberto changes his phone number? Does it update across the three systems automatically? Almost never. That’s why the discipline of IAM exists: to govern that orchestration.

The building blocks: attributes, claims, entitlements, and credentials

Now let’s get into the detail of the components. These four pieces are the operational vocabulary of IAM — the words you’ll hear every day if you work in this domain.

Attributes

Attributes are facts about the identity. If you’ve ever filled out a registration form in an app, you already know what they are: every field you filled in is an attribute. They can be immutable (date of birth), slow-changing (last name, department), or dynamic (current location, device in use).

Typical examples:

• First name, last name
• Email, phone
• Date of birth, ID number, tax number
• Department, manager, office
• Preferred language
• Last login date

Attributes live in the identity repository (Active Directory, LDAP, user database). Applications consume them to make decisions or to personalize the experience.

A useful question to ask yourself when designing a system: for each attribute, who writes it, who updates it, who reads it? Most “stale data” problems in an organization come from not answering those three questions.

Claims (assertions)

A claim is a digitally signed assertion that an issuer makes about an identity, addressed to a recipient. The key piece is the word signed: a claim is trustworthy because it comes with a cryptographic signature from the issuer.

A quick analogy: imagine a mutual friend tells you “this person is reliable, I lent them money and they paid me back.” You believe them not because you like the person, but because they come vouched for by someone you trust. A claim works the same way: if Google signs “this email belongs to María,” the receiving app trusts it because Google’s signature is hard to forge and comes from a source already on its trusted list.

When you log in with your Google account in a third-party app, what the app receives is a set of claims signed by Google. Those claims look like this:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890abcdef",
  "email": "maria@gmail.com",
  "email_verified": true,
  "name": "María García",
  "iat": 1714579200,
  "exp": 1714582800
}

If you’ve never seen a payload like this, let me translate: iss is the issuer (in this case Google), sub is María’s unique identifier within Google, email_verified: true is the claim the app actually wanted — knowing that the email truly belongs to her — and iat/exp are the issuance and expiration timestamps. The app doesn’t need to ask Google whether the email is really María’s. Google’s signature on the JWT is enough. That’s a claim.

Entitlements

Entitlements describe what the identity is allowed to do. If credentials are the key that opens the door, entitlements are what they let you do once inside: can you enter every room or only the lobby? can you move furniture or only look at it? They’re expressed as permissions, roles, scopes, groups, or policies, depending on the model.

Equivalence table by context:

The important distinction at this stage: entitlements aren’t evaluated at the moment you authenticate, but every time you try to do something. You log in once a day; your entitlements are checked every time you press a button. We’ll go deeper on entitlements when we get to xBAC authorization models in the authorization track.

Credentials

Credentials are what the identity presents to prove it is itself. The simplest metaphor: they’re the “keys” that open the door. Some keys are cheap and easy to copy (a password on a sticky note), others are expensive and very hard to duplicate (your fingerprint or a hardware key like a YubiKey). The more valuable what’s behind the door, the stronger the key should be. They’re classified by factor:

Modern credentials can be asymmetric (public/private key pair, as in FIDO2) instead of shared secrets like passwords. The important difference: with a password, you and the server share the same secret, so if the server leaks it, your identity gets compromised everywhere you used that same key. With an asymmetric credential like a passkey, the private key never leaves your device; the server only stores the public one, which by itself is useless for authentication. That practically eliminates phishing.

The assembly: how the pieces work together

So far we’ve seen each component separately. Now let’s put them together in one scene. The following schematic shows the full journey: it starts with a real-world subject (on the left), passes through a digital identity with its attributes and credentials, crosses two doors (authentication and authorization), and ends with an action that gets executed or blocked (on the right). Read it left to right as if it were the movie of a user trying to do something in an app:

flowchart LR
  accTitle: How the identity pieces work together
  accDescr: Left-to-right flowchart showing a subject represented by a digital identity built from attributes and credentials, passing through authentication to obtain a token of signed claims, then through authorization evaluated against entitlements to either allow or block the action.
  S([Subject]) -. represents .-> ID[Digital Identity]
  ATR[Attributes] --> ID
  CRED[Credentials] --> ID
  ID --> AUTH{Authentication}
  AUTH -->|OK| CLAIMS[Token with Claims]
  CLAIMS --> APP[Application]
  DER[Entitlements] --> AUTHZ{Authorization}
  APP --> AUTHZ
  AUTHZ -->|allow| ACTION[Action executed]
  AUTHZ -->|deny| BLOCK[Action blocked]

Reading the diagram: the subject is represented by an identity. That identity has attributes and credentials. When it authenticates, a token with signed claims is issued. The application receives that token. When the identity tries to do something, its entitlements get evaluated. If authorization approves, the action executes. If not, it gets blocked — and that “block” is what prevents the absurd bank scenario we started with.

Sequence diagram: claim issuance

Let’s go down a level and see what happens exactly when a user logs in. The following is a sequence diagram: actors appear in columns at the top, and time advances downward. Each arrow is a network call or an internal operation; the steps are numbered so you can follow them one by one like a recipe. If you’ve worked with APIs, this is essentially the trace of an OIDC login as seen from the outside:

sequenceDiagram
  accTitle: Sequence of a claim issuance during OIDC login
  accDescr: Sequence diagram with five actors (user, client app, identity provider, directory, protected API) showing the eleven steps from login to successful resource access, with credential validation, JWT signing, and authorization evaluation in between.
  actor U as User
  participant App as Client App
  participant IdP as Identity Provider
  participant Dir as Directory
  participant API as Protected API
  U->>App: 1. Login (username + password)
  App->>IdP: 2. Forwards credentials
  IdP->>Dir: 3. Validates credentials, gets attributes
  Dir->>IdP: 4. User attributes
  IdP->>IdP: 5. Builds and signs JWT with claims
  IdP->>App: 6. Returns token (JWT)
  App->>App: 7. Stores token in session
  App->>API: 8. GET /resource (Bearer token)
  API->>API: 9. Verifies JWT signature
  API->>API: 10. Evaluates claims and entitlements
  API->>App: 11. 200 OK + resource

This flow is the backbone of any modern OIDC-based authentication. Signed claims are what allow the API to trust the identity without having to query the IdP again on every call — and that’s what makes the system fast and scalable, instead of generating an avalanche of IdP calls every time you load a page.

A didactic note: notice that the IdP and the directory appear as separate things in this diagram. In reality many commercial platforms (Okta, Entra ID) bundle them together, so when you configure a “modern” IdP you’re also configuring the directory behind it. But conceptually they’re two different things — the directory stores identities, the IdP authenticates them and issues tokens.

Quick recap

Before closing, a mental image worth taking with you:

• A subject lives in the real world. You, your phone, a microservice.
• Each subject can have several digital identities — one per system where it exists.
• Each identity materializes in one or more accounts within concrete databases.
• Identities expose profiles that are partial views depending on context.
• Each identity has four components that make it operational: attributes (what’s known about it), credentials (what it proves itself with), entitlements (what it can do), and context (where it’s acting from right now).
• When an identity authenticates, a claim signed by an IdP is issued. When it tries to do something, its entitlements get evaluated against a policy.

If you understood that, you already have the vocabulary to talk to anyone in the IAM domain and follow along.

Test yourself

Three questions to check that the concepts landed. Try answering them in your head before moving on — and then prove it in the companion lab.

1. María uses an app to order food. Identify the subject, the identity, two possible accounts, and two profiles the system might expose.
2. Your team builds an internal system where employees approve expenses. What would the key attributes of each identity be, what entitlements would you differentiate, and what credentials would you recommend?
3. If an app receives a JWT signed by an IdP it doesn’t trust, what should it do and why?