zlacker

>>caust1+(OP)
> A passkey is a synced, discoverable WebAuthn credential.

This is my fundamental problem with passkeys: I don't want to use any syncing service.

To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors.

It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.

>>lapcat+Vr
I was messing with implementing webauthn the other day, mainly because I like public key authentication. I was hoping for something sort of like ssh keys. and they were close, so close, to having something good that could replace password auth. and then they break it by requiring a hardware token, Yes, a hardware token is better, but I am not going to require users get a hardware token. there are working software token systems built into the browser but they are gated behind dev tools, again something I am not going to ask of users. and just to spit in whatever goodwill they have left, to make it really unusable, there is this weird mandated "no user interface" policy in the standard. making near impossible to manage keys. The keys are critical in a public key auth system. but "no, we are disallowed, by the standard, to give you an easy mechanism to back up and restore keys"

If I were more conspiracy minded, I would suspect some sort of agent provocateur ruining our standards. However, I am unable to come up with a profit motive, so my only conclusion is incompetence.

>>somat+D61
> I was hoping for something sort of like ssh keys

SSH keys (and any other keypair shared across services) are a non-starter on the web for privacy reasons. (See also: `ssh whoami.filippo.io`.)

>>lxgr+aw1
The implementation ends up being a new key gets generated per domain, which is actually what you should be doing with your ssh-keys as well something like "ssh -i server.domain.net server.domain.net"

Because webauthn is such a nonstarter I am actually going to try and half-ass it using SubtleCrypto.sign() and friends. sort of mimic the webauthn api. This is really just a weekend project, nothing important. but I feel really stupid every time I work on it, mainly because of how ridiculous it is to have your key infrastructure managed by the service you are logging into.

However due to domain sandboxing I have half convinced myself it is as secure as using a cookie to auth the person, perhaps even a little better because I never have to see a secret. then fall into despair again on how stupid this whole endeavor is, because I could see the keys anytime I want to. (sighs, shakes fist at the sky) why could you have not made webauthn usable?