The vendor locking argument is less about "classical" WebAuthn and more about passkeys.
But even for "classical" WebAuthn it's still a valid issue.
The problem lies in:
1. attestation
2. browsers like chrome possible gate-keeping what can work as an authentication device (independent of attestation)
Attestation is a feature where each "batch" of authentication devices get a unique certificate burned in and report that back when registering a key through webauthn. There will be roughly at most 10_000 other people with the same cert. In many cases likely less.
And that is _highly_ problematic for many reasons. First while 10_000 sounds big, with just a bit additional fingerprinting information it allows a very unique fingerprinting of people across services (and devices you use to access the services). The combination of cert id + e.g. email + service + optional statistics about usability is _very_ saleable information, I mean a private health care provider would love to know that someone who might be one of their customers has signed up for a online anonymous alcoholic group or similar. They don't even need to know it's them for sure, just knowing it could be them with a 10% chance is enough to make sure to bump what their client has to pay "just to be save" the next chance the provider gets to do so.
Furthermore this are "burned in" certs so you can't have a different attestation certificate per service or anything like this without also having different physical devices, which in case of e.g. using your phone might be hard.
This "burned in" nature also means that some things can't have attestation, e.g. KeyPassXC or the TKey by nature can't (nor do want to) have this form of attestation. In turn if attestation is required this vendors are basically out of business.
But this isn't where the problems stop, attestation can also be used to find out what kind of device you have in general including an approximate date of production. So now the page you auth against knows you use a specific kind of YubiKey or e.g. that you use a specific phone produced in some specific time frame for authentication. This is very useful information for marketing as e.g. lifestyle and believes often influence buying decisions, not necessary in the current HSK market, but on the phone market which with passkey will likely become the most common HSK.
Furthermore this information can be used to remove agency from the user, e.g. through attestation a app can know that your HSK does support bio-metric authentication and in turn might force you to use it, even through you might not be able to do so because e.g. the fingerprint reader is broken or you had an op which makes face recognition impossible.
Lastly attestation allows applications to not work with HSK vendors they don't like even if they are standard conform. E.g. if Microsoft has beef with YubiKey they could reject them and make it look like a bug. Or a app you have for work could decide that using any HSK which isn't their partner (or from themself) is only usable if you pay a premium or similar.
Now the good part is WebAuthn doesn't require attestation. You can set attestation to none, and this can be done for devices which support attestation, too. E.g. Firefox does so by default.
The problem is if even just a small number of the big players (e.g. Google + Microsoft) decide they do require attestation on all logins it could be game over for _any form of privacy preserving 2FA for good for ever_ (except if regulators step in).
Worse through chrome and edge they can enforce requiring attestation for sides which do not want to enforce it and collect additional private information by sending the attestation information data to their ad-services. Don't forget that not to long ago edge had a bug which wasn't fixed for a long time which lead to it basically sending all links their user followed to bing, including magic sharing links like you e.g. know from google drive. So don't expect vendors to not a
And for the big players enforcing attestation through the ecosystem is as easy as flipping a switch. As most HSKs support attestation. Furthermore they could add additional requirements, like only accepting attestation from vendors which have gone through some very expensive security review done by companies of their choice (Google already does so for access to (large pars of) their oauth2 authenticated APIs). This could mean good-by to any smaller or new HSK vendors, and might majorly hurt phone vendors they don't like.
Now you might wonder why attestation exist if it's that bad. The reason is requirements for some enterprises like e.g. military contractors requiring FIPS certified devices. Attestation can be used to enforce this. It also can be used to e.g make sure your employees only use HSKs you gave to them.
IMHO the main problem I see is not that attestation does exist, but that it's often phrased as a good or desirable thing (instead of a necessary evil) by the groups pushing for WebAuthn/passkey making me believe that there is a extremely high risk of abuse of this feature by Google, Microsoft or similar in the not so distant future. Especially given that it can be monetary wise quite beneficial and could be forced down the throat of users without most realizing it.
I would prefer if attestation would by default always be off and the spec requiring vendors to support non-attested devices as long as the user (or company the user belongs to) doesn't require it. Require that attestation information must be enabled on the key instead of being enabled by default, etc. I.e. make it cumbersome enough so that it can't easily be abused but still usable for the rare military contractor like use case. Oh and also there should be ways to have more privacy preserving attestation, too.
EDIT: To be clear you don't have the whole cert with all device information burned in, but a private key + some metadata and you can look up all this information based on the metadata depending on the kind of attestation. I.e. it works similar to TPM attestation, but not necessary exactly the same (expect if you used a TPM as HSK then it's exactly the same).
EDIT2: Just to be clear WebAuthn is in general a grate idea and could even lead to more privacy if used nicely. But it sadly has also potential for abuse and the parts which allow abuse can't be stripped out for practical reasons. So I'm worried.
EDIT3: WebAuthn today is mostly used for second factor in 2FA but it has the potential to become the first factor or fully take over both factors. Providing a more secure and convenient experience. But if abused also enforce more control of big cooperation, leak ton of private information (especially to the big cooperation's) and remove agency from the user in a not really acceptable way.
EDIT4: China could use attestation internally to even more control their citizens if they want to (might not be worth the effort), e.g. requiring vendors to be whitelisted (hint: vendor leaks private keys to government) or coupling the citizen score to it in some way.
But even for "classical" WebAuthn it's still a valid issue.
The problem lies in:
1. attestation
2. browsers like chrome possible gate-keeping what can work as an authentication device (independent of attestation)
Attestation is a feature where each "batch" of authentication devices get a unique certificate burned in and report that back when registering a key through webauthn. There will be roughly at most 10_000 other people with the same cert. In many cases likely less.
And that is _highly_ problematic for many reasons. First while 10_000 sounds big, with just a bit additional fingerprinting information it allows a very unique fingerprinting of people across services (and devices you use to access the services). The combination of cert id + e.g. email + service + optional statistics about usability is _very_ saleable information, I mean a private health care provider would love to know that someone who might be one of their customers has signed up for a online anonymous alcoholic group or similar. They don't even need to know it's them for sure, just knowing it could be them with a 10% chance is enough to make sure to bump what their client has to pay "just to be save" the next chance the provider gets to do so.
Furthermore this are "burned in" certs so you can't have a different attestation certificate per service or anything like this without also having different physical devices, which in case of e.g. using your phone might be hard.
This "burned in" nature also means that some things can't have attestation, e.g. KeyPassXC or the TKey by nature can't (nor do want to) have this form of attestation. In turn if attestation is required this vendors are basically out of business.
But this isn't where the problems stop, attestation can also be used to find out what kind of device you have in general including an approximate date of production. So now the page you auth against knows you use a specific kind of YubiKey or e.g. that you use a specific phone produced in some specific time frame for authentication. This is very useful information for marketing as e.g. lifestyle and believes often influence buying decisions, not necessary in the current HSK market, but on the phone market which with passkey will likely become the most common HSK.
Furthermore this information can be used to remove agency from the user, e.g. through attestation a app can know that your HSK does support bio-metric authentication and in turn might force you to use it, even through you might not be able to do so because e.g. the fingerprint reader is broken or you had an op which makes face recognition impossible.
Lastly attestation allows applications to not work with HSK vendors they don't like even if they are standard conform. E.g. if Microsoft has beef with YubiKey they could reject them and make it look like a bug. Or a app you have for work could decide that using any HSK which isn't their partner (or from themself) is only usable if you pay a premium or similar.
Now the good part is WebAuthn doesn't require attestation. You can set attestation to none, and this can be done for devices which support attestation, too. E.g. Firefox does so by default.
The problem is if even just a small number of the big players (e.g. Google + Microsoft) decide they do require attestation on all logins it could be game over for _any form of privacy preserving 2FA for good for ever_ (except if regulators step in). Worse through chrome and edge they can enforce requiring attestation for sides which do not want to enforce it and collect additional private information by sending the attestation information data to their ad-services. Don't forget that not to long ago edge had a bug which wasn't fixed for a long time which lead to it basically sending all links their user followed to bing, including magic sharing links like you e.g. know from google drive. So don't expect vendors to not a
And for the big players enforcing attestation through the ecosystem is as easy as flipping a switch. As most HSKs support attestation. Furthermore they could add additional requirements, like only accepting attestation from vendors which have gone through some very expensive security review done by companies of their choice (Google already does so for access to (large pars of) their oauth2 authenticated APIs). This could mean good-by to any smaller or new HSK vendors, and might majorly hurt phone vendors they don't like.
Now you might wonder why attestation exist if it's that bad. The reason is requirements for some enterprises like e.g. military contractors requiring FIPS certified devices. Attestation can be used to enforce this. It also can be used to e.g make sure your employees only use HSKs you gave to them.
IMHO the main problem I see is not that attestation does exist, but that it's often phrased as a good or desirable thing (instead of a necessary evil) by the groups pushing for WebAuthn/passkey making me believe that there is a extremely high risk of abuse of this feature by Google, Microsoft or similar in the not so distant future. Especially given that it can be monetary wise quite beneficial and could be forced down the throat of users without most realizing it.
I would prefer if attestation would by default always be off and the spec requiring vendors to support non-attested devices as long as the user (or company the user belongs to) doesn't require it. Require that attestation information must be enabled on the key instead of being enabled by default, etc. I.e. make it cumbersome enough so that it can't easily be abused but still usable for the rare military contractor like use case. Oh and also there should be ways to have more privacy preserving attestation, too.
EDIT: To be clear you don't have the whole cert with all device information burned in, but a private key + some metadata and you can look up all this information based on the metadata depending on the kind of attestation. I.e. it works similar to TPM attestation, but not necessary exactly the same (expect if you used a TPM as HSK then it's exactly the same).
EDIT2: Just to be clear WebAuthn is in general a grate idea and could even lead to more privacy if used nicely. But it sadly has also potential for abuse and the parts which allow abuse can't be stripped out for practical reasons. So I'm worried.
EDIT3: WebAuthn today is mostly used for second factor in 2FA but it has the potential to become the first factor or fully take over both factors. Providing a more secure and convenient experience. But if abused also enforce more control of big cooperation, leak ton of private information (especially to the big cooperation's) and remove agency from the user in a not really acceptable way.
EDIT4: China could use attestation internally to even more control their citizens if they want to (might not be worth the effort), e.g. requiring vendors to be whitelisted (hint: vendor leaks private keys to government) or coupling the citizen score to it in some way.