Identification and identity proofing

Before anyone can authenticate, someone must decide who they are. Identification is the claim a subject makes; identity proofing is the process an organization uses, once, at enrolment, to establish that the claimed identity belongs to a real person and that the applicant is that person. Weak proofing undermines everything built on top of it: a fraudster who opens an account in someone else's name will pass every later authentication perfectly, because the credential really is theirs. This lesson covers identifiers and naming, the account types an organization must manage, how identity proofing works and how assurance levels describe its strength, and the digital identity programs emerging in Canada and the United States.

Identifiers and naming conventions

An identifier is the label by which a system knows a subject. Good identifiers are unique within their scope, so that two subjects never share one; persistent, so that they do not change when a person changes name or department; and ideally non-descriptive, revealing as little as possible about the person or their role. Uniqueness is essential for accountability. Persistence matters because logs and permissions reference identifiers for years; if an identifier is reused, a new employee can inherit the history and even the access of a former one. Non-descriptiveness is a defence against reconnaissance: an account called admin-payroll tells an attacker exactly which account to target.

Many organizations use two identifiers: an immutable internal identifier, such as a randomly generated employee number or directory object identifier, which never changes or gets reused, and a friendly login name or email address, which can change when a person marries or transfers. Applications should key permissions on the immutable identifier. Common naming schemes such as first initial plus surname produce collisions in any organization of a few hundred people, so they need a documented rule for duplicates and a ban on reusing names of former staff for a defined period.

import random
random.seed(114)
first = ['Amira','Ben','Chen','Dana','Eli','Fatima','Gabe','Hana','Ivan','Jia','Kofi','Lea','Malik','Nora','Omar','Priya','Raj','Sofia','Tom','Yusuf']
last = ['Singh','Smith','Tremblay','Nguyen','Brown','Wilson','Martin','Lee','Roy','Patel']
staff = [(random.choice(first), random.choice(last)) for _ in range(400)]
logins = [f[0].lower() + l.lower() for f, l in staff]
from collections import Counter
c = Counter(logins)
clashes = sum(n - 1 for n in c.values() if n > 1)
print('Staff:', len(staff), ' distinct first-initial logins:', len(c), ' people needing a suffix:', clashes)
# Chance two of n people receive the same random 6-digit identifier (birthday bound)
import math
for n in (500, 1000, 5000):
    p = 1 - math.exp(-n * (n - 1) / (2 * 10**6))
    print(f'{n:5d} random 6-digit IDs: chance of at least one collision {p:.1%}')

Staff: 400  distinct first-initial logins: 172  people needing a suffix: 228
  500 random 6-digit IDs: chance of at least one collision 11.7%
 1000 random 6-digit IDs: chance of at least one collision 39.3%
 5000 random 6-digit IDs: chance of at least one collision 100.0%

The output shows two things. Name-based logins collide constantly, so the collision rule is not an edge case. And even random numeric identifiers collide surprisingly often by the birthday effect, which is why the issuing system must check uniqueness rather than trust randomness. Identifiers are not secrets: user names appear in email addresses and logs, so security must never rest on keeping them hidden, although an organization can reasonably avoid publishing administrator account names.

Account types

An IAM program governs several kinds of account, each with different risks. Standard user accounts belong to one person for everyday work. Privileged or administrator accounts can change systems, and should be separate from the same person's everyday account so that reading email or browsing is never done with administrator rights. Service accounts are used by applications and scheduled jobs; they have no human behind them, often hold broad rights, rarely have their passwords changed and are a favourite target. Shared or generic accounts, such as a kiosk login, are used by several people and defeat accountability; they should be eliminated or tightly constrained. Emergency or break-glass accounts give access when normal authentication fails, and must be sealed, monitored and reviewed after every use. Guest and external accounts for contractors, partners and customers need sponsors and expiry dates.

How identity proofing works

Identity proofing establishes a link between an applicant and a real-world identity. NIST describes three steps. Resolution distinguishes the claimed identity from all others by collecting enough attributes, such as name, date of birth and address, to point to exactly one person. Validation checks that the evidence presented, such as a passport or driver's licence, is genuine, current and accurate, for example by inspecting security features or checking with the issuing authority. Verification confirms that the applicant is the person to whom the evidence belongs, for example by comparing a live selfie with the photo on the document, by an agent comparing the face in person, or by sending a code to an address of record.

Proofing can be in person, supervised remotely over video or unsupervised remotely through an app that reads a document and captures a selfie. Remote proofing scales and is convenient but faces document forgery, deepfake video and presentation attacks, so better systems use liveness detection and checks with authoritative sources. Organizations also proof employees as part of hiring: checking identity documents for employment eligibility, references and, where lawful, background checks. The identity established at hiring becomes the authoritative identity that drives provisioning, which is why personnel security and IAM are linked.

Knowledge-based verification, asking questions such as previous addresses or loan amounts, was once common for remote proofing. It is now considered weak because the answers are widely available from data breaches and social media, and NIST no longer accepts it for verification at higher assurance levels. Likewise, a phone number or email address shows that someone controls a channel, not who they are.

Assurance levels: IAL, AAL and FAL

NIST SP 800-63, the US Digital Identity Guidelines, separates digital identity into three independent dimensions, each with its own assurance levels. The fourth revision, SP 800-63-4, was finalized in August 2025 (checked October 2026). Identity assurance level, IAL, describes the strength of proofing. Authenticator assurance level, AAL, describes the strength of authentication, covered in lessons 3 and 4. Federation assurance level, FAL, describes the strength of assertions passed between an identity provider and a relying party, covered in lesson 6. Separating the dimensions lets a service choose, for example, strong authentication for an anonymous account (low IAL, high AAL), or strong proofing with moderate authentication.

Selecting the level is a risk decision. The guidelines ask the service owner to assess the impact of a proofing failure, from inconvenience to financial loss to harm to safety, and choose controls that match. Choosing too high a level excludes legitimate users who lack the required documents or cannot attend in person; revision 4 places new emphasis on equity and on offering alternatives, such as trusted referees who vouch for an applicant. Choosing too low a level invites fraud. In Canada, the Treasury Board Standard on Identity and Credential Assurance uses four levels of assurance for federal programs, and the Pan-Canadian Trust Framework maps similar levels across jurisdictions.

Digital identity programs

In Canada, digital identity is largely provincial, because provinces issue the foundational documents such as birth certificates and driver's licences. British Columbia's BC Services Card app lets residents prove who they are online to provincial and some federal services, and Alberta offers a verified Alberta.ca Account. Quebec's National Assembly adopted Bill 82, An Act respecting the national digital identity, in late October 2025; it makes the digital identity voluntary, requires user consent for each use and limits data sharing to what a transaction needs, with a phased rollout over the following years (check current status). Ontario's earlier digital ID plans were put on hold, so confirm the current position. Federally, the Government of Canada uses GCKey and Sign-In Partner options, and the Directive on Identity Management sets requirements for federal programs. The Digital ID and Authentication Council of Canada, DIACC, publishes the Pan-Canadian Trust Framework, a set of conformance criteria that public and private identity providers can be certified against, so that a credential issued in one context can be trusted in another.

For organizations, these programs matter in two ways. They may become accepted evidence for proofing customers and employees, reducing the need to collect and store copies of documents. And they raise the same privacy questions as any identity system: what data is shared, whether use can be tracked across services and how consent is managed. Verifiable credentials, digital wallets and selective disclosure, which let a person prove they are over 19 without revealing their birth date, are designed to reduce oversharing.

Registration and binding

Once proofed, the applicant is enrolled: an account is created and one or more authenticators are bound to it. Binding must be done securely, because an authenticator bound to the wrong person, or intercepted in transit, gives an attacker a perfectly valid credential. Good practice includes delivering initial credentials through a separate channel from the proofing session, requiring the user to set their own secret immediately, binding at least two authenticators so that losing one does not force weak recovery, and recording which authenticators were bound, when and by whom. Account recovery deserves the same rigour as enrolment, because attackers target the help desk and the forgotten-password page precisely because they are often the weakest path to an account.

Thinking like a manager

Identity proofing and identifier design are early decisions that are hard to change later. A manager should insist on unique, persistent identifiers keyed to an authoritative source, separate privileged accounts, owners and expiry dates for every non-standard account, and proofing and recovery processes whose strength matches the risk of the service. Exam questions often describe an attack that succeeded at enrolment or recovery; the best answer strengthens that process, not the login page.