That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.
I halfway expect a v2 specification where keys are only stored on a few "Certified Attestation-capable" providers (i.e. facebook, google, apple, amazon)
Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.
That's not what happened. He said quote "which would allow RPs to block you, and something that I have previously rallied against".
This is something that has been proposed that Tim fought against but mentioned in the thread to provide context of the types of kneejerk reactions the spec authors have had to push back against.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.
The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.
Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials.
Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
Are there any examples of any widely-used sites that are enforcing attestation?
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
Certainly a password manager like keepass would be no more complicated than trying to explain to her that she can no longer access her account because she broken her phone.