3 ms·
Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-sec
by jampekka 2y ago
Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ https://arstechnica.com/security/2024/12/passkey-technology-...
- reginald78 2y agoAnd one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.
- dcow 2y agoI was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing. AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
- dcow 2y agoPlatform/vendor lock-in != device bound