Comment by BoppreH
7 days ago
I think "online" here means "loaded in a device", as opposed to "sitting in a safe".
The protocol requires additional keys to sign a challenge during registration, so at best you have to load a pre-generated key from the safe when creating a new account. In practice, you generate a new key for every account, so between generating the key and storing it in your safe there's no backup but cloud sync.
This prevents using backup storage that is safer but inconvenient to access, and also prevents registering accounts on-the-go.
> "Online" in the sense of "loaded in a device", as opposed to "sitting in my safe".
The "device" can be entirely virtual. I've written a passkey-compatible OIDC provider for use on my homelab and it uses passkeys. But the passkeys are just in a SQLite database, which can be copied wherever.
That's not advisable for security, which is one reason I've not released the provider for others to use, but passkeys can operate just fine with that.
If I wanted, the private key itself just be in something like AWS KMS instead of a SQLite database, and it would all still work fine. Nothing about passkeys itself requires a hardware device or that the key be unexportable.
> Nothing about passkeys itself requires a hardware device or that the key be unexportable.
That's all true, but also not the point of this thread (offline backups) or the post (attestation limiting user freedom).
All of which have solutions in this thread too. Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
4 replies →