Chapter 2: Understanding digital identity

Introduction

The café-to-kiosk example introduces digital identity as a matter of recognition and relationships, not just accounts and credentials.

• Identity beyond account attributes: Explain how the café example contrasts human recognition built through repeated interactions with a kiosk that recognizes an account through an identifier and attributes. Describe why digital identity concerns relationships, not just logging in.
  Why it matters: It helps distinguish an account’s recorded information from the relationship that information is meant to represent.

Key terms: digital identity, digital relationships, identifier, attributes, credentials

2.1 What is digital identity?

This section defines digital identity in functional terms and explains why it matters for digital relationships and authorization.

• Functional meaning of digital identity: Explain that digital identity lets systems recognize, remember, and relate to people, organizations, things, services, and digital agents online.
  Why it matters: This definition gives you a practical way to discuss identity without getting stuck on everything the word can mean.
• Philosophical views of identity: Distinguish the bundle-of-attributes view from the view that identity must be tied to an underlying entity.
  Why it matters: The contrast shows why the book chooses a practical definition rather than trying to settle a philosophical question.
• Relationship-specific identity systems: Explain why an organization might use different identity systems for employees and customers.
  Why it matters: It explains why one organization may not use a single identity system for every relationship.
• Identity context for authorization: Explain how identity supports access-control decisions, especially in dynamic authorization.
  Why it matters: It connects digital identity to the access decisions that the rest of the book examines.

Key terms: digital identity, recognize, remember, relate, bundle theory, substance theory, attributes, identity systems, relationships, employees

2.2 The problems of digital identity

This section introduces the challenges of digital identity and why examining them can clarify the design and limitations of identity systems.

2.2.1 The proximity problem

This section explains why digital identity lacks the closeness of in-person relationships and how systems compensate for that distance.

• The digital proximity problem: Explain how a computer-mediated interaction differs from an in-person relationship and why that leaves digital identity systems relying on relatively weak signals.
  Why it matters: It explains why recognizing someone digitally is different from recognizing them face to face.
• Accounts and recognition mechanisms: Describe how digital identity systems respond to the proximity problem and name the drawbacks noted here.
  Why it matters: These familiar identity features are ways to compensate for the limited signals available to a remote system.

Key terms: proximity problem, weak signals, accounts, authentication mechanisms, attributes

2.2.2 The interoperability problem

Explains why digital identities do not work seamlessly across organizations and why existing interoperability protocols help without resolving the underlying problem.

• Fragmented organizational identities: Explain why people encounter many separate usernames, identities, and forms online, and describe the deeper problem of relying on organizations’ identity systems rather than having their own.
  Why it matters: This explains why sharing identity information between organizations does not, by itself, give people a seamless digital identity.
• Partial protocol solutions: Describe how SCIM and OpenID Connect help organizations cope with interoperability, while stating that neither solves the whole problem.
  Why it matters: It distinguishes useful ways to connect organizational systems from a complete solution to fragmented identity.

Key terms: identity layer for humans, interoperability problem, identity systems, SCIM, OpenID Connect, federating identity providers, interoperability

2.2.3 The flexibility problem

This section explains how limited identity-system attributes can leave authorization systems without the context they need.

• Identity attribute flexibility limits: Explain why an identity system may not provide every attribute an authorization decision needs, and why dynamic attributes may require data from other systems.
  Why it matters: An authorization system cannot rely on the identity provider alone for context it does not supply.

Key terms: schema, attributes, identity provider, dynamic attributes, authorization systems

2.2.4 The privacy problem

This section explains how digital identity and authorization can threaten privacy, while also identifying ways to protect it.

• Digital identity privacy risks: Explain how widespread storage of personally identifying information, reuse of that information, and centralized identity providers can threaten privacy.
  Why it matters: Identity systems can expose information even when they are performing their intended function.
• Authorization privacy and accuracy risks: Describe how authorization logs and requests for unnecessary attributes can worsen privacy, and why privacy concerns can make self-asserted data less reliable.
  Why it matters: Collecting more information for access decisions can harm both privacy and the reliability of those decisions.
• Privacy protection approaches: Explain how dynamic authorization can enforce limits on who accesses data and when, and state the control over sharing sought by self-sovereign identity.
  Why it matters: The same identity and authorization landscape that creates privacy risks can also support limits on access and sharing.

Key terms: personally identifying information (PII), central identity providers, authorization logs, access history, attributes, self-asserted data, dynamic authorization, self-sovereign identity (SSI)

2.2.5 The consent problem

This section explains why people often lack meaningful control over identity-data sharing and how dynamic authorization can worsen that consent problem.

• Granular consent barriers: Explain why consent in identity systems may not give people meaningful control over sharing their data.
  Why it matters: A consent option does not provide much control if people cannot make a practical, specific choice.
• Authorization attribute sharing: Describe how dynamic authorization can worsen the consent problem when it uses people's attributes.
  Why it matters: Attribute-based decisions can undermine consent if people cannot tell what they are sharing or why.

Key terms: consent, granular consent, identity data sharing, dynamic authorization, attributes, policy decisions, oversharing

2.2.6 The scale problem

This section explains why growing demands on digital identity systems create a scale problem, especially when organizations rely on dynamic authorization and zero-trust access checks.

• Identity infrastructure at scale: Explain how a growing number of services, organizations, and digital interactions makes identity harder to manage, and how under-resourcing identity infrastructure contributes to scaling problems.
  Why it matters: Identity infrastructure has to keep pace with the interactions it supports.
• Authorization demands on identity: Explain why dynamic authorization and zero-trust access checks increase the burden on identity systems, making scalable identity important for deploying dynamic authorization.
  Why it matters: Authorization cannot scale well if the identity information it depends on cannot scale.

Key terms: scale problem, identity infrastructure, dynamic authorization, principals, resources, zero-trust model

2.2.7 How identity problems affect authorization

This section explains why digital identity challenges affect the reliability of authorization decisions.

• Identity inputs to authorization: Explain how problems with digital identity affect authorization by making it harder to identify requesters, retrieve accurate attributes, and apply policies reliably.
  Why it matters: An access decision is only as dependable as the identity information it uses.

Key terms: digital identity, authorization, attributes, dynamic authorization

2.3 Identity and digital relationships

Identity systems are valuable because they support digital relationships, which shape the handling of identity attributes.

• Relationships as identity systems’ purpose: Explain that identity systems are built to support relationships rather than merely manage identities, and that each relationship determines which identity attributes are needed, used, and protected.
  Why it matters: Thinking about the relationship helps explain why an identity system needs particular information and protections.

Key terms: identity systems, relationships, identity attributes

2.3.1 Types of digital relationships

This section distinguishes three kinds of digital relationships, explains how they blend, and shows why their character should shape identity systems and access policies.

• Three digital relationship types: Distinguish transactional, interactional, and exploitative digital relationships by what happens in each and how the service uses a person’s identity or behavior.
  Why it matters: The kind of relationship helps determine what an identity system and its access policies need to support.
• Blended and evolving relationships: Explain why the three types are not rigid categories and how the Digital Relationship Triangle represents real relationships.
  Why it matters: A single label can hide important features of a relationship, including exploitative ones.
• Relationship-driven identity and access design: Explain how the relationship being supported should affect identity-system design and access policies, using the section’s contrasts among the three types.
  Why it matters: Access rules should fit what the relationship actually requires, not just what a service can collect.

Key terms: transactional relationships, interactional relationships, exploitative relationships, Digital Relationship Triangle, blended nature of relationships, identity attributes, rich memory, governance, transparency, authorization policies

2.3.2 Digital relationship properties

The section identifies three properties of digital relationships and explains how reliable identity supports authorization and useful access.

• Three digital relationship properties: Describe integrity, lifespan, and utility as properties supported by digital identity systems, and distinguish the roles of authentication and account management in maintaining them.
  Why it matters: These properties clarify what an identity system must sustain throughout a digital relationship.
• Authentication foundation for authorization: Explain why an access policy can grant permission to the wrong party when the identity supplied to it is misrepresented, even if the policy itself is sound.
  Why it matters: A sound permission rule cannot compensate for a mistaken identification of the requester.
• Relationship context and useful access: Explain how an identity system provides utility through access control and how the relationship’s context shapes the access or features it enables.
  Why it matters: Identity is useful not just for recognizing people, but for enabling appropriate actions in a particular relationship.
• Policy centered identity systems: Describe the section’s claim that moving authorization out of code and static lists makes policy central and expands the role of digital identity systems.
  Why it matters: The section connects identity’s usefulness to authorization that can serve both product features and security.

Key terms: integrity, lifespan, utility, account management, authentication, authorization, identity, access control policies, access control, subject

2.4 Naming and discovery

The section uses a No-Fly List mix-up to show how poor naming and discovery can cause an authorization failure.

• Naming errors and access decisions: Explain how the No-Fly List’s reliance on names led to Senator Ted Kennedy being treated as a banned traveler, and why his denied boarding was an authorization failure.
  Why it matters: An access decision can be wrong even when the restriction itself is applied as intended, if the system has identified the wrong person.

Key terms: naming, discovery, unique identifiers, authorization failure

2.4.1 The role of names in digital identity

This section distinguishes ordinary names from identifiers and explains why digital identity systems use identifiers to recognize parties in a relationship.

• Names and contextual meaning: Explain that names are shorthand labels for people, places, or things, and that a name may not be unique or mean the same thing without context.
  Why it matters: This distinction explains why a name alone may not reliably pick out one party.
• Identifiers within namespaces: Distinguish an identifier from a general name: it is unique within a namespace, enabling a digital identity system to recognize and remember a party in a relationship.
  Why it matters: An identifier gives a system a way to refer back to the right party in a digital relationship.

Key terms: names, context, identifier, namespace, digital identity systems

2.4.2 Tradeoffs in identity naming

This section explains the competing priorities in identity naming and why the right identifier depends on its intended use in authorization.

• Identity naming tradeoffs: Describe the naming properties a system may prioritize: human meaningfulness, uniqueness and non-reusability, resistance to impersonation and forgery, and decentralization.
  Why it matters: An identifier's useful qualities depend on the problem the system needs it to solve.
• Purpose-driven identifier choice: Explain why ACME might choose different employee identifiers and how its authorization needs determine the choice.
  Why it matters: Choosing an identifier should support the access decisions the organization needs to make.

Key terms: human meaningfulness, uniqueness and non-reusability, impersonation and forgery, decentralization, UUIDs, email address, employee number, directory distinguished name, opaque UUID, authorization policies

2.4.3 Namespaces and their role in identity

This section explains how namespace design keeps identifiers distinct and discoverable, and why four ways of organizing names create different authorization risks.

• Namespace design and authorization: Explain what a namespace does and why authorization can fail when identifiers are ambiguous, unstable, hard to discover, or untrustworthy, even if policy logic is sound.
  Why it matters: Correct access rules still need identifiers that point reliably to the right people and things.
• Centralized namespace tradeoffs: Describe how a single organization keeps names unique in a centralized namespace, and explain the portability and identifier-reuse risks illustrated by employee IDs.
  Why it matters: An employee number can remain in policies and records long after its original holder leaves.
• Hierarchical namespace tradeoffs: Explain how hierarchical names support discovery and delegated naming, and why organizational paths can become unsafe assumptions for policies after change.
  Why it matters: A path that helps find someone today may mislead access decisions after an organization changes.
• Flat namespace tradeoffs: Describe how flat identifiers avoid collisions across contexts and why their lack of meaning makes identity discovery and policy administration harder.
  Why it matters: Global uniqueness does not tell an administrator what an identifier represents.
• Federated namespace governance: Explain how federated namespaces combine local name assignment with global discovery, and why participants must agree on the meaning and trustworthiness of names and attributes.
  Why it matters: Recognizing a partner's email address is not the same as knowing what access its holder should receive.

Key terms: namespace, identifier, namespace boundary, centralized namespace, employee ID numbers, hierarchical namespace, DNS, LDAP, path, flat namespace

2.5 Identity system models

This section connects identity system models to naming and discovery, then explains why the model matters for authorization decisions.

• Namespaces and identity architecture: Explain that a namespace reflects the architecture of the identity system that manages it, so the model shapes how identities are created, authenticated, discovered, and trusted.
  Why it matters: An identifier makes more sense when you understand the system responsible for it.
• Identity models and authorization decisions: Explain that centralized, federated, and decentralized identity models balance control, interoperability, and security differently, and that the model affects authorization through the quality and timeliness of identity attributes.
  Why it matters: Authorization decisions depend in part on whether the identity information they use is reliable and up to date.

Key terms: namespace, identity system model, naming and discovery, centralized, federated, decentralized, identity attributes, authorization decisions

2.5.1 Centralized identity: Single authority, high control

This section defines centralized identity and explains its control benefits for authorization alongside its single-point-of-failure risk.

• Single authority over identity: Explain that a centralized identity system is provided and controlled by one entity, which determines how it is used.
  Why it matters: Identifying who controls an identity system helps explain its benefits and risks.
• Control and authorization benefits: Explain how organizational control lets a centralized system enforce tailored rules, keep governance within the organization, and more easily supply attributes for authorization decisions.
  Why it matters: The same control that simplifies identity governance can make identity information easier to use in access decisions.
• Single point of failure: Explain why reliance on a centralized identity system creates a single point of failure and why choosing its provider carefully matters.
  Why it matters: The benefits of central control must be weighed against the impact of a provider failure.

Key terms: centralized identity model, single entity, strong control and enforcement, governance, attributes, authorization decisions, single point of failure, identity provider

2.5.2 Federated identity: The backbone of modern identity systems

This section explains how federated identity connects identity providers and relying parties, how enterprise and online arrangements differ, and what benefits and risks federation brings.

• Federated identity roles and exchange: Explain what identity providers and relying parties do in federated identity and why their interactions use a protocol.
  Why it matters: These roles explain who supplies identity information when an application relies on an account managed elsewhere.
• Enterprise and online federation arrangements: Distinguish enterprise federation from online single sign-on in their agreements and typical examples.
  Why it matters: The same basic identity arrangement can rest on very different organizational agreements.
• Federation benefits and dependencies: Describe the convenience and operational benefits of federated identity alongside its dependence and privacy risks.
  Why it matters: A simpler sign-in experience can come with a significant concentration of access and information in the IdP.
• Identity attributes for authorization: Explain why attributes supplied by an IdP may be insufficient for authorization decisions.
  Why it matters: A successful federated sign-in does not guarantee that an application has all the information needed to decide what the person may do.

Key terms: identity provider (IdP), relying party (RP), federated identity, assertions, enterprise federation, trust frameworks, single sign-on (SSO), click-through license, deplatforming, privacy

2.5.3 Decentralized identity: Shifting control to users

This section explains how decentralized identity lets people hold and present credentials, why that gives participants more choice, and what trust and adoption challenges remain.

• Holder-Controlled Credential Model: Describe how trusted parties issue credentials that people hold in wallets and present to relying parties (RPs) for cryptographic verification, without a central authority managing everyone’s identity.
  Why it matters: This is the basic model behind the section’s claims about user control and cross-organization use.
• Participant Choice and Consent: Explain why the model is decentralized and how participants’ choices give people more control over consent and privacy, including sharing across organizations without prior agreements.
  Why it matters: Participant choice explains both the model’s privacy benefit and its usefulness across organizational boundaries.
• Decentralized Trust Frameworks: Explain why RPs may still need trust frameworks and how accreditation can help an RP judge an issuer without an agreement with that issuer.
  Why it matters: A credential can be checked technically while the RP still needs a basis for trusting its issuer.
• Trust and Adoption Limits: Describe the two limitations identified here: the difficulty of deciding whom to trust and the challenge of getting issuers and RPs to adopt the model.
  Why it matters: These limits explain why user control does not make decentralized identity the easiest choice for every use case.

Key terms: decentralized identity, self-sovereign identity (SSI), credentials, cryptographic wallet, RPs, decentralized, consent problem, privacy, prior agreements, trust frameworks

2.6 Trust and confidence

The section notes that frequent references to trust in identity and authorization reflect the relational nature of identity.

• Trust and relational identity: Explain why the section connects trust with digital identity: trust comes up often in identity and authorization discussions, reflecting identity’s relational nature.
  Why it matters: This connection frames why trust is relevant to discussions of digital identity.

Key terms: trust, relational nature of identity

2.6.1 The difference between trust and confidence

Distinguishes trust from confidence and explains how evidence can reduce vulnerability without eliminating reliance on others.

• Trust and confidence spectrum: Distinguish trust from confidence, using the flight example to explain why they are not an either-or choice. Explain how greater confidence can reduce vulnerability and the need to trust.
  Why it matters: The distinction helps you describe what evidence supports and where you still depend on other people or organizations.

Key terms: trust, confidence, vulnerability, spectrum

2.6.2 Trust and confidence in digital relationships

The section explains why digital relationships can inspire false confidence and how system design, cost, and governance affect the balance between confidence and trust.

• False confidence in digital interactions: Explain how the proximity problem makes users and operators vulnerable to deception, using phishing as an example of poorly designed systems inspiring false confidence.
  Why it matters: It explains why asking people to be cautious is not a substitute for trustworthy signals from the system.
• Confidence and trust tradeoff: Describe the kinds of identity-system risks that affect confidence and explain how design, cost, and governance shape the balance between confidence a system inspires and trust it requires.
  Why it matters: It gives you a way to discuss confidence in an identity system without treating trust as a single, automatic property.

Key terms: proximity problem, phishing, confidence signals, false confidence, confidence, trust, identity system, governed and maintained

2.6.3 Technical confidence in identity systems

The section explains how account management, authentication, attribute verification, and auditing provide technical confidence in digital identities.

• Basis of technical confidence: Distinguish technical confidence from trust and explain what technical controls are meant to protect against.
  Why it matters: It clarifies what the identity system can substantiate technically and what still depends on oversight.
• Account life cycle confidence: Explain why confidence in an account depends on managing its identity information from enrollment through deactivation.
  Why it matters: A correctly established account can still become an unreliable basis for access decisions later.
• Authentication assurance: Explain how authentication strength affects confidence that the entity logging in is the account creator.
  Why it matters: An account's information is less useful if the system cannot be confident who is using it.
• Verified and current attributes: Explain why authorization decisions require critical attributes to be verified and kept current even when authentication and policies are sound.
  Why it matters: An access decision can be wrong when it relies on a false or outdated fact about an identity.
• Audit evidence and feedback: Describe how systematic review of logs contributes to confidence in an identity system.
  Why it matters: Operational evidence lets people assess whether identity controls are working, rather than merely assuming they are.

Key terms: trust, technical confidence, cryptographic, procedural, and policy-based controls, account life cycles, enrollment, identity attributes, revoked, stale credentials, authentication mechanisms, authentication factors

2.6.4 The limits of technical confidence

This section explains why technically reliable identity systems cannot eliminate human and policy risks, and why effective access control also needs social trust and governance.

• Limits of technical confidence: Explain why correctly functioning identity, authentication, and authorization systems cannot eliminate insider risk or guarantee that access policies are adequate, correct, or fair.
  Why it matters: A system can enforce a rule perfectly while the person using it—or the rule itself—still creates risk.
• Social norms and perceived trust: Describe how social expectations can affect whether people regard an identity system as fair or trustworthy, even when it operates correctly.
  Why it matters: People’s experience of fairness can affect trust independently of a system’s technical reliability.
• Governance alongside technical assurance: Explain what governance contributes when technology alone cannot provide confidence, and why dynamic authorization needs both technical confidence and policy governance.
  Why it matters: Secure access control requires both reliable technical enforcement and human decisions about which rules should apply.

Key terms: technical confidence, insider threats, policies, social norms, trust, reciprocity, governance, policy governance, dynamic authorization

2.7 Privacy, authenticity, and confidentiality

Introduces privacy, authenticity, and confidentiality as related considerations for designing authorization policies.

2.7.1 Distinguishing privacy from confidentiality

The section distinguishes privacy, confidentiality, and authenticity, then uses an encrypted health-clinic visit to show why hiding content does not necessarily hide a conversation.

• Privacy and confidentiality distinctions: Distinguish communications privacy, information privacy, confidentiality, and authenticity as the section defines them.
  Why it matters: These distinctions clarify which aspect of an interaction a protection actually addresses.
• Encrypted consultation metadata: Explain what TLS hides and leaves visible in Alice's virtual health-clinic visit, and why the visible details matter.
  Why it matters: The example shows why an encrypted conversation is not necessarily a private one.
• Attribution and repudiation: Explain why visible metadata does not by itself prove Alice had the conversation, and what Earl would need to establish.
  Why it matters: It separates observing a connection from proving which person was behind it.

Key terms: communications privacy, information privacy, metadata, confidentiality, authenticity, TLS, IP addresses, domain name, confidential, repudiate

2.7.2 Managing tradeoffs

The section explains why authenticated interactions can lack communications privacy while still preserving information privacy through limits on who may see records of the interaction.

• Authentication and communications privacy: Explain why a confidential bank login is not private in the sense of hiding who is communicating, and why a pseudonym may not hide someone from an identity platform.
  Why it matters: It keeps confidentiality and pseudonymity from being mistaken for anonymity to the service.
• Functional information privacy: Explain how a banking interaction can be functionally private even though the bank identifies the customer and keeps logs.
  Why it matters: Privacy is not all-or-nothing: limits on access to records matter even when the service knows who you are.

Key terms: authenticity, confidential, communications privacy, authenticated session, pseudonymous interactions, functionally private, information privacy, need to know

2.7.3 Functional privacy

The section explains how governance and policy-based access control support functional privacy while balancing privacy, security, compliance, and usability.

• Functional privacy and governance: Explain that functional privacy means systems access and process only necessary information, and that governance sets the rules about who may access data and under what conditions.
  Why it matters: Privacy needs both a limit on data use and rules that make that limit enforceable.
• PBAC support for privacy: Describe how PBAC can enforce fine-grained access, allow policies to be managed and reviewed apart from underlying systems, and automate decisions without unnecessarily exposing sensitive data to people.
  Why it matters: Access rules can protect sensitive information without blocking legitimate work or exposing it to unnecessary reviewers.
• Three digital trust concerns: Distinguish privacy as control over sharing, confidentiality as protection from unauthorized access, and authenticity as assurance that identities, credentials, and transactions are legitimate.
  Why it matters: Keeping these concerns distinct helps explain what an access policy does—and what else a trustworthy system needs.
• Balanced policy driven protection: Explain why policies must balance protection and compliance with usability: weak protection has serious consequences, while overly restrictive rules create costs and friction.
  Why it matters: Good protection must also let people complete legitimate work.

Key terms: functional privacy, governance, authorization policies, Policy-Based Access Control (PBAC), fine-grained access, decoupling authorization, privacy, confidentiality, authenticity, dynamic authorization

2.8 From identity to authentication

This section connects identity’s role in managing relationships to the quality of authorization decisions and explains why authentication must establish continuity before access is decided.

• Identity systems and relationships: Explain that identity systems primarily help digital systems recognize and maintain relationships with entities over time, rather than simply store accounts or enable logins. Describe how ACME uses different identity systems for different kinds of relationships.
  Why it matters: The relationship an identity system serves shapes what the system needs to recognize and remember.
• Identity quality in authorization: Explain why authorization needs more from identity than evidence that someone logged in. Describe how reliable identity signals support policy decisions and how ambiguous or stale inputs weaken them.
  Why it matters: Even a well-written policy can make a poor decision when its identity inputs are unreliable.
• Authentication and relationship continuity: Explain why authentication comes before deciding what an entity may do: it checks whether the party interacting now is the same party in the established relationship and with what confidence.
  Why it matters: An access decision must be grounded in confidence that it applies to the party actually interacting with the system.

Key terms: identity systems, digital relationships, relationship type, authorization, dynamic authorization, decision-making context, signals, attributes, authentication, relationship

2.9 Summary