Passkeys and Modern Authentication

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate.

On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

> Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

How do I sign in from multiple computers?

There are multiple solutions to this, with tradeoffs. Doesn't change the fact that the service should only want a public key, and you should only give the service a public key. That's where this new complexity is being forced on users and developers. You need to be able to sign in, or let your users sign in, but you can choose how complicated of a key management strategy to have.

You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).

Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.

You are describing passkeys. All of this applies to the passkey scheme.

Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.