Digital identity

Digital identity certificates are cryptographic credentials that bind a public key to a verified entity — a person, organization, or device. In practice, they answer a single question: "Can this entity be trusted?" Without them, TLS handshakes, PSD2 open banking flows, and eIDAS-compliant transactions have no verifiable foundation.

What a Digital Identity Certificate Actually Contains

A certificate is a structured data file, not a password or a token. It is issued by a Certificate Authority (CA) and follows the X.509 standard. Every certificate carries a fixed set of fields:

As of 2026, the CA/Browser Forum mandates a maximum TLS certificate validity of 47 days for publicly trusted certificates — down from 398 days. This compresses the issuance and renewal cycle significantly and pushes most organizations toward automated certificate lifecycle management (CLM).

Types of Digital Identity Certificates

Not all certificates serve the same purpose. Conflating them leads to compliance gaps.

TLS/SSL certificates — authenticate a server to a browser or API client. Three validation levels exist:

• Domain Validation (DV): confirms domain control only. Issued in minutes.
• Organization Validation (OV): confirms legal existence of the organization. Takes hours to days.
• Extended Validation (EV): highest scrutiny, confirms jurisdiction, physical address, and operational existence.

Client certificates — authenticate a user or device to a server. Used in mutual TLS (mTLS), which is required in PSD2 for Third Party Provider (TPP) to bank communication.

Code signing certificates — bind a software publisher's identity to executable code. Required for kernel-mode drivers on Windows and mandatory for apps distributed through major platform stores.

Email (S/MIME) certificates — sign and encrypt email at the message level. Relevant for compliance with PIPEDA and Quebec's Law 25 when sensitive personal data is transmitted by email.

QWAC (Qualified Website Authentication Certificate) — a specific certificate class defined under the eIDAS Regulation. QWACs are issued by Qualified Trust Service Providers (QTSPs) and carry legally recognized identity information. In the context of PSD2, QWACs identify payment service providers in open banking API calls. Canada does not currently have a direct equivalent, but federally regulated financial institutions operating in the EU must comply with eIDAS requirements for their European-facing services.

How Digital Identity Works: The Verification Chain

Trust in digital certificates is not self-declared — it flows through a chain:

1. Root CA — a self-signed certificate stored in OS and browser trust stores (e.g., Mozilla NSS, Microsoft Root Store, Apple Root Store).
2. Intermediate CA — signed by the root. Issuance happens at this level to protect the root from operational exposure.
3. End-entity certificate — the certificate your server, user, or device presents.

When a browser or API client receives a certificate, it walks the chain from the end-entity up to a trusted root. If any link is missing, expired, or revoked, the connection fails.

Revocation is checked two ways:

• CRL (Certificate Revocation List) — a signed list published by the CA at regular intervals. Download size can reach several MB for large CAs.
• OCSP (Online Certificate Status Protocol) — a real-time query to the CA's OCSP responder. OCSP Stapling allows the server to cache and include the response in the TLS handshake, reducing latency.

As of 2026, Chrome no longer performs soft-fail OCSP checks by default. Certificate revocation is primarily enforced through CRLite (Mozilla) and Chrome's CRLSets — compressed, frequently updated revocation databases embedded in the browser.

Digital Identity in Canadian Compliance Context

Canada's digital identity landscape sits at the intersection of several frameworks:

OSFI Guideline B-13, updated in 2023 and enforced through 2025-2026 exam cycles, specifically addresses cryptographic key management and certificate inventory. Institutions are expected to maintain a complete certificate inventory and demonstrate they can replace any certificate within 24 hours in response to a compromise.

Certificate Lifecycle Management: Where Organizations Fail

The most common operational failure is not a cryptographic weakness — it is an expired certificate that was not renewed. In 2024, expired certificates caused documented outages at financial institutions, healthcare networks, and government portals across North America.

A mature CLM process covers:

• Discovery — automated scanning to find every certificate in the environment, including shadow IT and third-party services.
• Inventory — centralized database with owner, expiry, issuer, and renewal method recorded per certificate.
• Issuance automation — ACME protocol (RFC 8555) enables automated issuance and renewal without human intervention. Supported by Let's Encrypt and most enterprise CAs.
• Rotation policy — defined SLA for emergency replacement (e.g., 4 hours for public-facing TLS, 24 hours for internal services).
• Alerting — expiry alerts at 90, 30, 14, and 7 days. With 47-day max validity in 2026, 90-day alerts are no longer sufficient on their own.

Organizations running more than 500 certificates typically need a dedicated CLM platform rather than spreadsheets. Platforms integrate with Active Directory, Kubernetes (cert-manager), HashiCorp Vault, and CI/CD pipelines.

Mutual TLS and Its Role in API Security

Standard TLS authenticates the server to the client. mTLS adds client authentication — the client also presents a certificate that the server validates. This is mandatory in several contexts:

• PSD2 open banking — TPPs must authenticate to bank APIs using eIDAS certificates (QWAC for transport, QSEAL for request signing).
• Zero Trust architectures — device identity certificates replace network perimeter as the trust boundary. Each workload presents a certificate; no implicit trust based on IP.
• Service mesh environments — Istio, Linkerd, and similar platforms issue short-lived certificates (often 24-hour TTL) to each service for east-west traffic encryption and authentication.

The operational challenge with mTLS is certificate distribution and rotation at scale. A Kubernetes cluster with 200 pods, each holding a 24-hour certificate, rotates roughly 200 certificates per day. Manual processes break immediately at this scale.

Key Algorithms and Their Current Status

NIST finalized its post-quantum cryptography standards in 2024 (FIPS 203, 204, 205). Migration timelines for critical infrastructure extend to 2030, but certificate issuance systems are beginning to test hybrid classical/PQC certificate chains now.