|
Top-level
 @SiteRelEnby @whitequark it's an Apple/Microsoft/Google joint effort to use device-bound (which usually means TPM / enclave-bound) asymmetric credentials as authenticator. It's also a FIDO standard: https://fidoalliance.org/passkeys/ I don't think Google are pushing for it any more than the other implementers? 8 comments
 @delroth @SiteRelEnby (I am upset about Google as the browser vendor specifically. FIDO is fine, passkeys are fine technologically probably) @whitequark @SiteRelEnby yeah... I suspect that Chrome insists on hardware backing or system level credentials management to store the passkeys, and Linux doesn't really have a working API for either. Could DBUS to GNOME Keyring :P  @Raqbit @delroth @whitequark @SiteRelEnby Linux doesn't have a first class authenticator API yeah. If you want to, you can buy a security key and get passkeys that don't sync. I wouldn't recommend that to most people since you have to do your own backup management but if you're a linux user maybe they're less of a footgun. There's nothing stopping vendors from implementing their own passkey syncing solutions for linux (dashlane and 1password have implementations, maybe more out there?)  @whitequark @delroth Why the fuck don't sites just let me give them the public half of an ECDSA key? No need for random potentially-trojanised standards...  @SiteRelEnby @whitequark @delroth And you get to pick the curve parameters, right? 😈 |
Gregory's Server
@SiteRelEnby @whitequark double checking the relevant standards: Google definitely contributed, but they're far from the only names on there, and they don't seem overrepresented either?
https://www.w3.org/TR/webauthn/
https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html