Hacker News Reader

Comment by sreevisakh | Hacker News Reader

I don't think I understand passkeys. The best I could make out is that it uses an asymmetric key pair for authentication. How is this different from self-signed TLS client certificates (like the ones used in Gemini protocol) or CertFP used in IRCv3?

View on HN

The difference is that: 1) this is accessible and usable by anyone running a modern operating system+browser. mTLS client certs need to be provisioned which is one of the major reasons why it is only used in enterprise settings. And 2) passkeys and WebAuthn are privacy preserving features. You can't track users across different websites with FIDO2 devices (mTLS does not preserve your privacy at all). This was one of the core principals that went into the design of FIDO(2) from the beginning.

Client certs as implemented on Gemini and IRC are self-signed. They are enrolled on the service after they're created. They don't need enterprise level capabilities. In fact, even the creation of these certificates are automated on many clients (eg: Lagrange Gemini browser, soju IRC bouncer). You don't even think of them as certificates. They're considered as identities.

And regarding the privacy. You can deploy as many certificates/identities as you want on multiple accounts and sites. It's not possible to track them across sites or even across accounts, since there is no CA involved.

Passkeys are indeed similar to that approach. There's no CA infrastructure, so they can be considered "self-signed certificates" (though they do not present as certificates, and currently cannot be used for TLS to my understanding, though I don't think there are technical reasons you couldn't wrap them in x509 metadata and use them as such it's just not a core use case), generated per-service, and enrolled as they are created. Passkeys add a couple enterprise features back in than just "raw self-signed certificates" in the form of optional "attestations" designed in a somewhat privacy-preserving way to prove the type of device that owns the key and in deeper enterprise modes the serial number of the device.

Because here the private key totally inaccessible, stored on the user's authenticator device, which is analogous to a certificate authority in this case. Part of the WebAuthn spec provides for methods for trusting (or distrusting) authenticator apps, and presumably browsers themselves will assist in blocking untrusted authenticators as they do with CAs.

Reply on news.ycombinator.com