Hacker News Reader

Comment by notatoad | Hacker News Reader

this is entirely on the webapps.

webauthn, as designed, can't be used to lock anybody into any authentication method, because the apps that use it should support adding as many different webauthn methods as you want. it only has the possibility to be a lock-in if you are restricted in the number of authentication methods you can add for a third-party service you want to authenticate to. and FWIW, apple and google both recommend supporting infinite passkeys, and have implemented that in their own webapps. any fearmongering about webauthn/fido/passkeys being a vendor lock-in is not backed up by current facts.

View on HN

WebAuthn has a specific feature called “attestation” where an app can only accept keys from a specific vendor as verified by vendor-provided signatures (that the user agent cannot forge). I personally doubt it will be used for this kind of lock in (it’s currently mostly used by companies for internal authentication so they can make sure you only use the brand of WebAuthn keys issued by them) but it’s not technically infeasible with the current standard.

If you want to see an outside of the box use of the attestation feature, take a look at Cloudflare’s “Cryptographic Attestation of Personhood” [1]. Basically they use the attestation key to tie the WebAuthn challenge to a real vendor, so if spammers make their own fake WebAuthn keys they can block them wholesale. I’m sure some Cloudflare skeptics will jump in and point out all the ways that could be abused.

[1]: https://developers.cloudflare.com/support/about-cloudflare/b....

The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website. That process, 'Client to Authenticator'[1] relies on the goodwill of the 'Clients', which for all intents and purposes are: Chrome, Safari, Edge, Firefox, Windows 10+, iOS, and Android.

Maybe they'll always support cross-platform USB/NFC keys (they probably will), but I don't want an external device(s), especially if I have to remember to set up multiple devices for every site to have redundancy.

[1] https://fidoalliance.org/specifications/download/

> The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website

Yes. Good thing there's an open standard called webauthn, supported by all the major vendors, that defines an interoperable way to get the result of those crypto functions back to the websites that need them.

The person you're replying to is clearly talking about the portability of the private key material across multiple, heterogeneous clients - which webauthn doesn't touch.

Be better.

> webauthn, as designed, can't be used to lock anybody into any authentication method

It only supports HTTP as I understand it, and won't work for other protocols like SMTP or IMAP.

What does work, regardless of application level protocol is using TLS certifications on both the client and server side in combination with a username and password for authentication.

WebAuthn doesn’t even support HTTP technically. All of the communication between the relying party and the user agent is non-standard and is handled by JavaScript today.

Reply on news.ycombinator.com