Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors.

I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.

I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".



> by software not written by OS vendors.

In an ideal world, I'd prefer that to.

In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them.

As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys.

> the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.

Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing).

And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: