Who goes there¶

Before the move, every account recovered through the same mailbox, and nobody had drawn what that mailbox recovered through. Authentication is the glue between the other layers. A registrar, a mail provider, a forge and a host can be four unrelated companies and still form one tightly coupled system if they share a login identity, a recovery address or an authentication provider. So the scraps for this layer are a drawing, not a list. For each provider: the login identity, the recovery email, the second factor, the recovery codes, the backup identity, any OAuth provider, the admin account and the billing account. Then the arrows. Domain, email, registrar recovery is one. Email, CodeFloe, repository, webhook, statichost, domain is another, and it looked nicely spread out until the same mailbox turned out to be the recovery mechanism for every box on it.

Who owns the account¶

The first question for each provider was which identity actually owns the account: a personal address, a domain address, a provider username, a separate administrative identity, an OAuth identity. The visible username is not the dependency. A CodeFloe account called purplelantern looks independent while its recovery hangs off one mailbox, and a hosting account with a different username can be tied to the same address. The drawing records both, and the second one is the arrow.

The loop¶

Recovery email is one of the strongest edges in the graph. If the registrar recovers through post@purplelantern.eu, and that address is at Proton, the domain depends on the mail service for recovery, which is fine. The dangerous shape is domain, mail, domain: losing the domain blocks the mailbox while losing the mailbox blocks recovery of the domain. The test that got asked was whether, with the domain gone, the important accounts could still be recovered. The answer was no until the recovery codes went into the vault, something that is not on the loop. An ordinary operational identity and a recovery identity are different things, and the recovery identity is better for not being used every day. Its job is to be available when the ordinary path is broken.

Factors¶

Passwords, authenticator apps, hardware keys, passkeys, SMS and email are not equal in recovery. SMS depends on the mobile provider, email on the mail system, an authenticator on the device and its backup, a hardware key on possession and registration. No one factor is superior everywhere, and for the accounts that count two independent paths are more use than one clever path that becomes inaccessible at the wrong moment.

Passkeys remove passwords and phishing, and add the question of where the passkey lives: on a hardware key, in the operating system, in a password manager, or in a browser’s synchronisation service. The last two are another cloud dependency. A passkey in a synchronised ecosystem is convenient and considerably less independent than a hardware key kept separately. There is no hardware key yet. A European-made one is on the list. Until it arrives the second factor is an authenticator app owned by a US company, which puts that company on every arrow that has a second factor, and that is the reason the key is on the list. Passwords are in KeePassXC, the local application and nothing in the cloud. When the key comes there will be two, in different places, so that losing one is not a ritual involving the services being recovered. Owning a key is not the point. Each service also keeps a second registered method for recovery.

Recovery codes get downloaded once and forgotten. They are credentials, and they went into the KeePassXC vault with the other critical secrets: encrypted, available without the affected service, backed up with the vault, and labelled with the right account. The dangerous arrangements are the only copy on the computer that just died, and the copy in cloud storage behind the account being recovered.

No OAuth¶

OAuth removes a password and creates a large dependency. CodeFloe behind a Google login is no longer independent of Google; hosting behind a GitHub login inherits GitHub’s availability and recovery chain. An otherwise European provider becomes indirectly dependent on a US identity provider because “sign in with X” was easier on the day. Every account on the new stack is a direct one with its own credentials. OAuth stays useful. Where it is used it gets an arrow on the drawing.

Admin and billing¶

An administrator account reaches billing, DNS, deployment, repository administration, user management, API keys and recovery settings, which makes it a high-value node. For each service the drawing says who can administer it and how that administrator is recovered. For a one-woman company both answers are the same person, so that account gets the codes in the vault, and the hardware key when there is one.

Billing is its own edge because an account can stay technically valid and become unusable through payment failure. The billing account has a login, a recovery address, a second factor, a payment method and an invoice archive, and a service can fail because the infrastructure is down or because the infrastructure is fine and the renewal cannot be paid. Billing is where authentication meets the financial layer.

Counting arrows¶

A provider list is useful. The edges are more so. Registrar to Proton to recovery email looks fine until Proton recovers through the same registrar, at which point the two depend on each other. CodeFloe, webhook, statichost, domain, Infomaniak DNS looks separated until CodeFloe’s login depends on the same domain email that depends on statichost serving the site, at which point the apparent separation hides a shared control path. Authentication belongs across the graph and not inside the security section of each service.

The way the trouble was found was by counting arrows through each identity. Suppose the mailbox is the recovery address for the registrar, both forges, the host and the bank, and the registrar holds the zone that routes the mailbox: one node on every arrow, and one loop. Suppose the password manager holds the passwords for all of those and for the mailbox: a second node on every arrow. The authenticator is a third node on every arrow that has a second factor, and a hardware key would take its place there. Three identities carry the stack today, and one of them has a US company behind it. An account on five arrows is more interesting than the five vendors at the ends of them, and the most important node on the drawing is the small mailbox that everything uses for recovery.

The drawing¶

                  ┌── second factor
   critical  ─────┼── recovery codes in the vault
   account        └── hardware key, when there is one
                            │
                   independent identity
                            │
              ┌─────────────┼─────────────┐
          registrar       email        Git forge
              │             │              │
             DNS         hosting       deployment

Direct administrative accounts, recovery email independent of the service being recovered, an authenticator on every account that takes one and the recovery codes in the vault, a hardware key still to come, no OAuth, billing mapped separately, recovery identities separated from operational ones with no circular recovery, and credentials exportable where the service permits. Not an elaborate identity system. A boring one. Boring is excellent when the alternative is discovering at 14:37 that the only person who can reset the registrar account is an email address whose domain expired at 14:12.

Authentication is a route by which an external action travels through an otherwise European stack. A provider is designated, the account is suspended, the email is unavailable, recovery is unavailable, and other accounts become inaccessible. Or a US identity provider goes, the OAuth account with it, and a European service is locked. Or the domain account’s recovery email fails, domain administration is blocked, and the website and mail follow. None of it requires a server to move. The control plane has been disconnected. Zero US authentication dependencies is not the target. No US service as the irreplaceable root of the stack is.

The primary mailbox is gone, what now?

• Can the registrar, DNS, the forge, hosting, banking and the vault still be reached, a second factor still authenticate, recovery codes still be retrieved, billing still be changed, and a new recovery address still be established?

• With the phone that holds the authenticator gone, do the codes in the vault do the job?

• With the domain gone, can the important accounts still be recovered?

If the answers are mostly yes, authentication is connective tissue. If they are no, authentication has become the infrastructure. The dangerous dependency is rarely the provider at the end of the arrow. It is the account sitting in the middle of five of them.

Nobody in Lancre has ever asked Granny Weatherwax to prove who she is, and it is not because they have a system.