Digital Identity: Claims, Credentials, Accounts, and Control

A person does not have one universal digital identity.

They have accounts, credentials, names, roles, attributes, devices, relationships, and reputations used in different contexts.

A digital identity system decides which claims about an entity are trusted, who can present or verify them, for what purpose, and with what control or recovery.

Identity is a governance and privacy system as well as a login mechanism.

A concrete example: proving age

A service needs to know whether a user is over a threshold.

One design collects a full identity document containing name, address, date of birth, and document number. Another accepts a signed age-over-threshold credential and learns only the required fact.

Both can support eligibility, but the second reveals and retains less information.

Identifiers

An identifier distinguishes an entity within a scope:

username,
account ID,
employee number,
email,
device ID,
or public key.

Identifiers are not necessarily permanent or globally unique. Reusing one identifier across contexts makes tracking and data linkage easier.

Attributes

Attributes describe an entity:

age,
role,
membership,
address,
qualification,
or account status.

Attributes have issuers, freshness, confidence, and purpose. “Employee” should expire when employment ends; “licensed professional” may require a current registry check.

Credentials

A credential is evidence supporting claims.

It may be:

password or passkey,
access card,
certificate,
signed digital credential,
identity document,
or token.

Different credentials provide different assurance. Possessing an email inbox is not equivalent to an in-person identity check.

Authentication

Authentication establishes that a current actor controls an account or credential.

Methods include:

passwords,
passkeys,
hardware security keys,
one-time codes,
biometrics,
and certificates.

Use phishing-resistant methods for high-value access and protect session tokens after login.

Authorization

Authentication answers “who or what is acting?” Authorization answers “what may this identity do now?”

Roles, attributes, relationships, consent, and resource policy shape access. A valid former employee credential should not grant current payroll access.

Re-evaluate authorization when context or risk changes.

Identity proofing

Proofing connects an account to a claimed real-world entity.

It may use documents, databases, in-person checks, trusted organizations, or existing relationships. Stronger proofing creates friction, privacy collection, and exclusion risk.

Use assurance proportional to consequence. A discussion forum does not need the same proof as a pension account.

Federation

Federation lets one identity provider authenticate users for another service.

It reduces password proliferation and centralizes security, but creates dependence on the provider, attribute mapping, account linking, and outage handling.

The relying service must validate issuer, audience, signature, time, and claims rather than merely accepting a token-shaped string.

Single sign-on

Single sign-on improves usability and centralized deprovisioning.

It also concentrates impact: compromise or outage can affect many services. Protect administrator accounts, use strong authentication, limit token scope and lifetime, and maintain emergency access procedures.

Recovery

Account recovery is part of authentication security.

Attackers target support staff, email resets, phone-number transfers, and weak knowledge questions. Recovery should match account value and create alerts, delays, or human review for risky changes.

Users also need a humane path after device loss or disability.

Selective disclosure

Selective disclosure reveals only required claims.

Instead of sharing a full birth date, a user may prove “over 18.” Instead of sharing a home address, they may prove residency in a region.

Technical support varies, and metadata can still enable correlation. The verifier should request the minimum claim.

Pseudonymous identity

Some communities benefit from stable pseudonyms without public legal names.

Pseudonyms can build reputation and accountability while protecting people from harassment or political risk. Platforms may maintain private enforcement mechanisms without displaying civil identity broadly.

Real-name policies can exclude or endanger users.

Identity linking

Linking accounts across devices and services can improve recovery or fraud detection, but it also creates surveillance and mistaken merges.

Require a defined purpose, confidence, correction process, and separation of unrelated contexts. A shared household device should not cause two people to become one profile.

Reputation

Ratings, history, and trust signals become part of platform identity.

They can be manipulated, biased, or difficult to transfer. Explain important reputation effects, allow correction, detect coordinated abuse, and avoid permanent penalties from old context.

Lifecycle

Identity lifecycle includes:

creation,
verification,
attribute changes,
credential rotation,
suspension,
recovery,
delegation,
deactivation,
and deletion.

Automate deprovisioning and reconcile identity sources so stale accounts do not retain access.

Delegation

People sometimes need another person or service to act for them:

caregiver,
accountant,
parent,
assistant,
or software agent.

Do not solve this by sharing a password. Create scoped delegation that states the actor, permitted resources, allowed actions, duration, and revocation.

Show the principal what was done on their behalf and require stronger approval for high-consequence changes. Delegation should survive ordinary device replacement but end promptly when a relationship changes.

Knowledge check

How do identifiers and attributes differ?
Why are authentication and authorization separate?
What tradeoffs accompany stronger identity proofing?
How does selective disclosure improve privacy?
Why is recovery part of the security model?

The one idea to remember

Digital identity is a system of scoped identifiers, claims, credentials, trust, and control. Good designs match assurance to consequence, minimize disclosure, separate authentication from authorization, support secure recovery, and give people meaningful correction and lifecycle rights.