Yes, this is exactly the problem.

Multiple pieces of software vying to be your passkey provider, often using dark patterns so you don’t realize you’re making a choice, and not using the term “passkey” so people are using the technology without knowing what it is or how to research it.

Kind of reflects the state of the web today, where every company wants to be your intermediary in every interaction, from making a purchase to transcribing a meeting.

▲

thewebguyd 2 days ago | parent [-]

> Multiple pieces of software vying to be your passkey provider,

Which entirely defeats the point of using passkeys. There shouldn't be a passkey provider the "provider" is your device's TPM/secure enclave + your biometric challenge. They are supposed to be mathematically non-exportable, device-bound.

▲

unscaled 2 days ago | parent | next [-]

"supposed" is doing a lot of heavy-lifting here. According to who? The FIDO2 or Webauthn standards? Or in a perfect world?

FIDO 1.0 started as two different standards: UAF and U2F. U2F was for USB keys used as second factors (so almost always stored in a TPM-like chip and device-bound, but not provided by your platform and there could be multiple of them). UAF were either provided by your platform or by any software and there was no requirement for them to be stored in TPM. Back in the day, very few platform had any FIDO support built-in, so in practice UAF was always done in software (usually based on whatever biometrics/TPM the hardware provided).

So competing options were the default for early FIDO, getting a default platform option is something that came later.

▲

sib 2 days ago | parent | prev | next [-]

Yeah - and as a user, I don't want my device manufacturer to have that level of influence or control over the authentication that I use for unrelated services.

▲

JohnFen 2 days ago | parent | prev | next [-]

> They are supposed to be mathematically non-exportable, device-bound.

Which would make the whole scheme unworkable (at least for me).

▲

l11r 2 days ago | parent [-]

I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.

▲

crote 2 days ago | parent [-]

Except enrollability. Got a new account? You need physical access to both tokens to enroll it. Got a new token? You'll have to individually enroll every website - provided they even support multiple tokens at all...

Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.

	▲	l11r a day ago \| parent \| next [-]
		I believe it was DOA because it defeated the main idea of tokens.
	▲	a day ago \| parent \| prev [-]
		[deleted]

▲

Itoldmyselfso 2 days ago | parent | prev [-]

The anti-phising benefits are still very much there even if you sync them to pw manager. Yes it introduces single point of failure (pw manager), but at the same time you no longer need to go reset all your passwords to every service you use if you happen to lose that device. Tradeoffs.