Digital Identity

Architecture

← Back to Digital Identity
🧭 Purpose

The objective is to separate identity from implementation.

Every component within the architecture should have a single responsibility.

No single vendor should own my identity.

Replacing any individual component should require little or no change to the rest of the system.

πŸ—ΊοΈ Architecture Overview
DIGITAL IDENTITY
Identity
Main email identity path
Current implementation: Personal domain
Routing
Current implementation: Cloudflare DNS
Identity Layer
Current implementation: SimpleLogin
Mailbox
Current implementation: Proton Mail
Online Services
Amazon Microsoft GitHub PayPal HMRC Banks
Authentication
Supporting capability
Used across the architecture
YubiKeys
Passkeys
LastPass
Recovery
Supporting capability
Disaster recovery and inheritance
Recovery Codes
LastPass Inheritance

The diagram shows responsibility and separation of concerns rather than process flow. Responsibilities are stable. Current implementations can change without affecting the rest of the architecture.

βš–οΈ Core Principles
  • I own my domain.
  • My domain is my identity.
  • Authentication should use open standards wherever possible.
  • Passwords should disappear over time.
  • Hardware-backed authentication is preferred.
  • Every online service should have its own unique identity.
  • Recovery should always be possible.
  • Simplicity is preferred over unnecessary complexity.
🧱 Architecture Layers

The architecture is divided into layers.

Identity Domain ownership.
Routing DNS.
Identity Layer Email aliases.
Mailbox Mail storage.
Authentication Passwords, passkeys and hardware keys.
Recovery Disaster recovery and inheritance.

Each layer has a single responsibility.

πŸ“Œ Current Status
Planning

The architecture has been agreed.

Implementation has not yet begun.

Individual components will be documented as they are implemented.

🧩 Architecture Components
Cloudflare 🟒 Documented
SimpleLogin 🟑 Planned
Proton Mail 🟑 Planned
YubiKeys 🟒 Documented
Passkeys 🟑 Planned
LastPass 🟒 Documented
Recovery 🟑 Planned
Decision Log 🟑 Planned

Each component will be documented in detail over time. Status: 🟒 Documented, 🟑 Planned, βšͺ Not Started.

πŸ“œ Architecture Decisions

Every important architectural decision is recorded here with an ID so that future pages can reference it.

AD-001 Own a personal domain. Approved
The domain is the foundation of the identity. Owning it outright keeps the identity portable and independent of any single vendor.
AD-002 Separate identity from mailbox provider. Approved
Email addresses belong to the identity layer, not the mailbox. The mailbox provider can be replaced with little or no change to the rest of the system.
AD-003 Use one unique email alias per online service. Approved
Every online service has its own identity. A breach or leak at one service exposes only that alias, which can be retired without affecting anything else.
AD-004 Use hardware-backed authentication wherever possible. Approved
Hardware keys provide the strongest available protection against phishing and credential theft, so they are used wherever a service supports them.
AD-005 Prefer passkeys over passwords whenever supported. Approved
Passwords should disappear over time. Where a service supports passkeys they are used in place of a password.