[yomlica8]

> I personally feel safer that passkeys aren't sync'd across multiple vendors' products.

Last time I checked into these hardware attestation was part of the specification but the ability export them from a vendors platforms is not. In practice that will mean unapproved platforms can be shut out and walled gardens strengthened. Which will happen sooner or later because it can. Apple supposedly zeroes their attestation but that is only a partial mitigation and relies upon the values of a giant corporation not changing its mind for any host of business reasons. And it does nothing to stop other platforms.

[aseipp]

FIDO itself specifies that attestation can be used but it's extremely likely browsers aren't going to ever support it for the same reason Apple has publicly said they won't: because attestation is a misfeature for Passkeys, because it completely eliminates the (very important and large) ability to synchronize Passkeys across devices using third party apps or built in browser mechanisms. Having to manually re-enroll every device is like a step backwards 10 years into the past from a usability POV. Device-attestation for passkeys was always 100% DOA for this reason, because without it, they can't form a suitable password replacement in the existing ecosystem, where synchronization is basically expected.

[yomlica8]

Bizarre they would make room in the specification for a DOA misfeature no one is going to use and everyone hates. Why not remove it from the spec and place the requirement of synchronization support into the spec instead?

[dwaite]

Not that everyone hates it. Competing models of usability/openness.

Security keyfob vendors have had attestations for years because they were selling primarily to corporate markets who have closed user bases and stringent authentication requirements, with some also provided to early adopter consumers.

Platforms and password managers are targeting consumer use cases, where preventing the user from leveraging the product would be a terrible thing, as would the 'user agent' problem where later entrants to the market have to beg to be on every site's allow list or lie and claim to be another product.

The synchronization doesn't break attestations. The idea of sites rejecting authenticators that synchronize means that attestations have become an anti-feature in the consumer space.

[aseipp]

I can't read anyone's mind. I assume it's simply because passkeys can be used outside the browser, in theory for arbitrary applications, and like every standard, it tries to satisfy a large set of users, there are tradeoffs, and some might want attestation. It's just that browsers and password managers are two use cases of the standard that don't want it, because it largely eliminates one of their major selling points, which is that they're synchronized like a password is today, so there's a clear UX flow/user upgrade path.

[JohnFen]

> Why not remove it from the spec and place the requirement of synchronization support into the spec instead?

I believe it's there to support the use case of companies who want to ensure their employees are using company-approved devices and methods to interact with company systems.

It's a reasonable use case.

[kstrauser]

I don't know that I've encountered a service that allows exactly one passkey. Everything I've tried either doesn't support passkeys at all, or supports multiple. In the latter case, add an iOS/Android passkey and something separate like a YubiKey. If one gets lost or you stop using it, the other still works.