Digital Identity Definitions matter more than they first appear, because the same word often means different things to a privacy lawyer, a developer, and a help desk agent. When a team says “verify the user,” one person pictures a passport check while another pictures a password prompt.
This glossary sets out the core terms in plain language, shows how they relate, and points out the pairs most often confused. It is written for readers managing their own accounts and for staff new to identity and access management who need a shared vocabulary before choosing tools or writing policies.
Why Precise Identity Terms Prevent Costly Mistakes
Loose vocabulary causes real design errors. A product manager who treats “logged in” as “proven to be a real, named person” may approve a feature that exposes sensitive data to anyone who created a free account with a fake name.
The opposite mistake also happens. A team that confuses authentication with identity proofing may demand a government ID at every login, adding friction and collecting far more personal data than the service ever needs. Customers leave, and the organization now stores documents it must protect.
Clear definitions also help in contracts and audits. When a vendor promises “strong identity verification,” a precise vocabulary lets you ask whether that means document checks at sign-up, multifactor authentication at login, or both. Those are different controls, with different costs, risks, and privacy consequences.
Precision also speeds up incident response. When an account is misused, the team needs to know quickly whether the failure was in proofing, authentication, or authorization, because each points to a different fix.
Subjects, Entities, and Principals
An entity is anything that can have an identity in a system: a person, an organization, a device, a software service, or even a physical asset. Many security failures involve non-human entities, such as an automated script running with powerful, forgotten credentials.
A subject is the entity an identity describes or that is currently acting. In NIST SP 800-63, the same person is called an applicant during proofing, a subscriber once enrolled, and a claimant while authenticating. Standards documents often switch between these words as the process moves forward.
A principal, common in software and cloud platforms, refers to any identity that can be authenticated and granted permissions, whether a user, a group, or a service. When an access log names a principal, it is telling you which identity performed the action, not necessarily which human sat at the keyboard.
Identity, Identifier, and Account Are Not the Same Thing
An identity is the collection of attributes that describes an entity within a particular context. You have a workplace identity, a banking identity, and a gaming identity. They describe the same person but contain different facts and are governed by different organizations.
An identifier is a value that points to one identity within a namespace, which is the scope where the value must be unique. An email address, a customer number, or a Decentralized Identifier (DID) are all identifiers. Identifiers can be public, private, permanent, or disposable.
An account is the record a specific service keeps so that an identity can sign in and use it. One identity can have several accounts, such as a personal and a business profile with the same bank. Deleting an account does not always delete the identity data the organization holds elsewhere.
Keeping these three apart clarifies privacy questions. Asking “which identifiers does this app collect, and can they be linked to my other accounts?” is far more useful than asking whether the app “knows who I am.”
Attributes, Claims, and Assertions
These three terms describe information about a subject at different levels of trust. They are easy to blur because they can contain the same data, such as an email address or date of birth.
Attribute
An attribute is a single property of an identity, such as name, age, role, or nationality. Some attributes are self-asserted, meaning the person typed them in without proof. Others are verified, meaning a trusted party checked them against evidence.
Systems should label which is which, since a self-asserted birth date proves nothing about age. A good data model stores the source and verification date next to each sensitive attribute.
Claim
A claim is a statement that a subject has a certain attribute value, offered for someone else to accept or reject. “This user is over 18” is a claim. In W3C Verifiable Credentials, an issuer makes claims about a subject.
The credential packages those claims with a digital signature so a verifier can check where they came from. Accepting a claim is always the verifier’s decision, based on how much it trusts the issuer.
Assertion
An assertion is a structured message from one system to another stating facts about an authenticated subject. An identity provider sends an assertion to a website after a successful login. SAML 2.0 calls these assertions directly, while OpenID Connect delivers similar information in a signed ID token.
Assertions usually expire within minutes to limit misuse if one is intercepted. The relying party must also check the signature, intended audience, and expiry before trusting any assertion.
Credentials Versus Authenticators
People use “credential” loosely for anything that gets them in, but standards draw a useful line. In NIST terminology, a credential binds an authenticator to a subscriber’s identity, while an authenticator is the thing the person possesses or knows and uses to prove control.
Passwords, phone-stored passkeys, hardware security keys, and one-time code apps are authenticators. The record that ties a specific passkey to your account is part of the credential. In everyday speech, the two words often overlap, which is acceptable as long as the team knows the difference.
The term digital credential is also used for issued documents, such as a mobile driver’s license or a verifiable credential showing a university degree. These carry attributes signed by an issuer. They answer “what is true about this person?” rather than “is this the same person who logged in last time?”
The Roles in an Identity Transaction
Most identity exchanges involve a small cast of roles. One organization can play several of them, but naming each role clarifies who is responsible for what when something goes wrong.
- Issuer: creates and signs a credential, such as a government agency issuing a digital ID.
- Holder: keeps the credential and decides when to present it, usually the person it describes.
- Verifier: checks a presented credential and decides whether to accept it.
- Identity provider (IdP): authenticates users and sends assertions about them to other services.
- Relying party (RP): the website or application that accepts an identity provider’s assertion.
- Credential service provider (CSP): in NIST usage, the party that proofs subjects and issues or registers their authenticators.
The issuer, holder, and verifier triangle comes from the verifiable credentials world. The identity provider and relying party pair comes from federation. Both patterns describe trust passing from one party to another, and many real systems combine elements of each.
Proofing, Verification, and Authentication Defined
Identity resolution is the step of narrowing a claimed identity down to one unique person within a population. Two people named Maria Lopez in the same city must be told apart before any further checks make sense.
Identity validation confirms that the evidence presented, such as a passport or utility bill, is genuine, current, and accurate. Identity verification then confirms that the person presenting the evidence is the person it describes, for example by comparing a live selfie with the document photo.
Together, resolution, validation, and verification make up identity proofing. Authentication comes afterward and repeats on every visit. It does not re-establish who you are in the real world; it only confirms that you control the authenticator bound to an account that was proofed earlier, or never proofed at all.
Authorization, Entitlements, and Permissions
Once a subject is authenticated, a separate set of terms describes what they may do. Getting these wrong leads to the most common access problem in organizations: people quietly accumulating rights they no longer need.
- Authorization: the decision to allow or deny a specific action on a specific resource.
- Permission: a single allowed action, such as reading a file or approving an invoice.
- Role: a named bundle of permissions assigned by job function, the basis of role-based access control.
- Entitlement: the full set of permissions an identity currently holds across systems.
OAuth 2.0 is an authorization framework. It lets a user grant an application limited access to their data without sharing a password, but it does not by itself tell the application who the user is. OpenID Connect adds that identity layer on top. Confusing the two has led to insecure “login with” implementations.
Assurance and Trust Terminology
Assurance is the degree of confidence that an identity process produced the right result. NIST SP 800-63 splits it into three dimensions: identity assurance level (IAL) for proofing, authenticator assurance level (AAL) for login strength, and federation assurance level (FAL) for assertions passed between systems.
A level of assurance is not a quality score for the person. It describes the strength of the evidence and controls used. An account at a low level may belong to a completely honest user; the system simply has less proof of who they are.
A trust framework is the set of rules, contracts, and technical requirements that lets organizations rely on each other’s identity decisions. The EU eIDAS regulation, sector schemes in banking, and university federations are examples. Their specific requirements vary, so check the governing body’s official documentation before relying on them.
Privacy Terms You Will Meet in Policies
Personal data is any information relating to an identified or identifiable person. Under the GDPR, biometric data used to uniquely identify someone is a special category with stricter rules. Other countries and US states define these categories differently, so local law determines the details.
Pseudonymous data replaces direct identifiers with a code, but someone holding extra information could still re-identify the person. Anonymous data, in the strict sense, cannot be linked back to an individual by any reasonably likely means. Many datasets labeled anonymous are actually pseudonymous.
Linkability describes how easily two records or sessions can be connected to the same person. Data minimization means collecting only what a purpose requires, and selective disclosure means revealing only chosen attributes from a credential. These terms let you judge a privacy policy instead of simply trusting its tone.
Putting the Vocabulary to Work
Start small. In your next project meeting or vendor call, replace vague phrases with precise ones. Instead of “we verify users,” say whether you proof identities at enrollment, authenticate with phishing-resistant methods, or both, and at which assurance levels.
When writing internal documentation, define each term once in a shared glossary and link every policy to it. Include examples drawn from your own systems, such as which fields are self-asserted and which are verified. New staff learn faster, and auditors find fewer contradictions.
As an individual, use the vocabulary to ask sharper questions. Which identifiers does this app collect? Is my age self-asserted or verified, and by whom? Which party is the identity provider here? Clear questions tend to produce clear answers, and vague answers become a useful warning sign.
The vocabulary will keep growing as passkeys, digital wallets, and new regulations spread. Treat your glossary as a living document, review it when you adopt a new standard, and retire terms your systems no longer use.