[geoctl]

Great effort. I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements during registration which means the relying party never really knows whether the authenticator's public key is actually generated by a real security key, TPM, etc... or just generated by software. I guess FIDO MDS can currently act as a solution to some degree but it might possibly break passkeys legitimately generated by software such as password managers, not to mention that when it comes to TPMs for example, the process is messy and unpredictable. Many TPMs don't even send their own entire x5c because of size and storage limitations.

[jiveturkey]

> I honestly doubt that any B2C or even the vast majority of B2B relying parties do verification of attestation statements

It took Apple to implement passkeys, for FIDO auth to become as popular as it is today. Apple does not attest because they were lazy. So yes, AFAIK only a few finance sites require attestation. (For internal auth, many IdPs can optionally require attestation, from limited signing authorities. Through federation this attested auth can be used elsewhere but I don't know of any mechanism for asserting that to any relying party.)

Yes, lazy. They knew that passkeys needed to be portable to other devices. Otherwise backups (well, recovery) would be impossibly difficult, as is the case with U2F today. The way the keys are passed around by Apple does not expose them, but they didn't bother to build an ecosystem where an attestation could also be portable (think: Security World). Why bother (it's fairly hard) when you can just not attest, and you have the weight to force everyone to accept it anyway? As long as you are within the Apple ecosystem, using a legitimate hardware-generated passkey, the attestation doesn't matter anyway. So screw everyone else.

FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests.

Now to get back to your doubt, if a registration is attested, I would be surprised if it is ignored.

[cyberax]

> Apple does not attest because they were lazy.

It's not "lazy", it's "impossible". If you want to have synced keys, you need to have them unencrypted. Otherwise, you need to be able to establish secure links between various secure hardware storage devices.

Apple can do that within their infrastructure, perhaps. But there's just no way to do that across multiple vendors.

> FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests.

Why? Passkeys are a perfect replacement for login/password pairs. Their implementations can also be secured as much as possible by each vendor.

And you _can_ require attestation in your WebAuthn implementation, if you think that your data is too precious.

[jiveturkey]

> But there's just no way to do that across multiple vendors.

Sure there is!

Since some superior body (FIDO) needs to declare which are the valid (or "most valid") attestation certs, not unlike the web PKI, and attestation (at higher levels) "demands" that keymat be held strictly secure by the attesting device, the CXP can be modified such that if the keymat passes between two attesting (and "arms length") authenticators, both at the same FIDO MDS level (or receiver greater), a bit is set in the exchange which tells the new/receiving authenticator to include ED in the attestation statement. That ED will indicate that the keymat passed from the original authenticator to the new authenticator, securely ie without ever being wrapped in a way that the user themselves (thus malware) had access to wrapping keys. This ED could include an original attestation as well, or not. Probably not since it wouldn't be against a nonce. Anyway, the RP can see this ED and then accept the new attestation even against a different one at registration time.

Of course this requires use of CXP and not some proprietary (frictionless) self-sync mechanism. Making that CXP "friendly" is a bunch of work, the actual hard part IMO. There's a lot more I could go on about but everyone will have lost interest by now.

Apple doesn't care about portability, the opposite in fact. Claiming that as the reason is quite a stretch. But I'm not speaking to that, just to the possibility (very much so) of such an interoperable sync between attesting but disparate authenticators.

Yes, an RP can require attestation, and yes an RP can require that attestations be FIDO MDS certified, anyway. What Apple has done is made their own job easier, out of laziness I say, because without attestation, within their own ecosystem they now don't need to create "Security Worlds" where they can attest (with same attestation cert) across synced devices. This benefits Apple, and actually Apple users, since users' keys are safe/secure if using Apple authenticators, whether attested or not, and whether RP cares or not! But the weight of Apple means that relying parties have to give up on attestation since Apple doesn't do it.

Using attestation wouldn't preclude software authenticators such as ye olde password managers, so it wouldn't force a lockout of small tech that other sibling posts are claiming are Apple's virtuous motivations. As you are correctly noting, RPs can require attestation -- well, RPs can also not require attestation if your data is not all that precious. Just as some large U2F RPs didn't require attestation. (UX, not attestation, was more the issue for U2F.) FIDO can still make a strongly worded recommendation to keep attestation optional, but eg let users know they are using an "L1" not an "L2" authenticator. Apple could have pushed to make that happen, instead of pushing non-attestation. So I still submit they took the easy/lazy way out.

> perfect replacement

hardly. at least not so far as has been realized today. (perfect is too strong a word)

[WorldMaker]

> Apple does not attest because they were lazy.

Apple has made clear statements in places such as WWDC talks that they believe attestations are bad for consumer privacy and consumer choice (migrating between Passkey providers, using Password Managers of their choice). They support attestations in very specific enterprise scenarios, so they didn't lazily ignore the work altogether, they just locked it behind a security fence (MDM environments).

Apple has put in extra work to champion other (optional) parts of the spec trying to provide some of what attestation was built to do, but in more privacy-focused/privacy-preserving ways.

> FIDO should have rejected this approach but from the very beginning they were captured by the largest corporate interests.

From the standpoint of consumer Passkey privacy it certainly feels a lot more that attestations were the capture by the largest corporate interests (both Google and Microsoft championed for them as core parts of the specs), and Apple's lone dissent of the big three is the one thing stopping FIDO from having made attestations required rather than optional.

[lxgr]

> Apple does not attest because they were lazy.

Apple used to support attestation, so while their decision to discontinue it for passkeys might have many possible motivations, laziness is the least likely in my view.

My personal take is that they've done the world a favor by removing it. If they hadn't, Google would have probably followed suit (possibly even doing it in software using some handwavy "Safety Net" arguments), and 1Password, Bitwarden, Keepass etc. would be locked out of more and more sites.

[geoctl]

I believe there is more to the problem than just laziness from the relying party side. The problem is what do you verify against? It's not as easy as in, for example, TLS handshake where browsers/HTTP clients have well-defined root CAs to verify the provided server cert against. It's easier for security keys (e.g. yubikeys) where you can just use the FIDO MDS service but there are many other uncovered use cases such as TPMs and browser/password manager generated passkeys. The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators. And since you mentioned Apple, as far as I know and I could be wrong for their newer products, it doesn't even provide real attestation statements to begin with like in Android or Windows Hello devices. The entire standard is currently practically based on TOFU "trust me bro, I am a hardware-based generated key lol"-tier registration process.

[fredfish]

> The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators.

This is not an accurate description of the point of Fido phishing resistance. It isn't to make a bank feel happy the user has a hardware key unless you choose attestation. It is to make the user happy that if they click the key they know is hardware on the wrong site then that site can't MITM a site they intend to authenticate to.

(Stopping users from reusing the protocol for security between passwords and real hardware keys is basically just forcing the DRM for SaaS aspect of attestation on people because you can. If you aren't the kind of institution that issued real tokens to account holders then it is none of your business.)