This is why knowing what technical terms mean matters.
What they’re saying is: the FIDO spec allows website operators to specify which passkey implementations they trust for authentication to their site. If your passkey implementation does not follow the spec around how it secures secrets and validates user auth flows, you risk that some sites will not trust your software as a viable passkey option.
As a comparison: imagine I made an HTTP client called “wurl”, and it was like curl but when users used it with authenticated requests, it emitted their credentials in plaintext logs on their laptop. Site operators could say “I’m gonna block requests where the user agent is wurl, because we don’t want our users to think they’re making secure requests and not catch this credential mishandling”.
No free software principles have been broken here: site operators (relying parties) are free to determine which auth implementations they are willing to interact with. Users are free to stop using sites that block auth implementations they think shouldn’t be blocked. No primitive of free software demands that site operators interoperate with something just because it’s a FOSS client.
Users should have the freedom to choose their implementations, or the entire point of Free Software is nullified and becomes useless. Take a look at what is happening with the Android attestation APIs, users of GrapheneOS (a libre and more secure variant of Android) are blocked from running mandatory government apps or almost mandatory banking apps, or even just fast food apps. Or the FSFE Router Freedom campaign. Or the mobile networks blocking devices that can share their access with other devices, or other devices they don't like.
Service operators being required to allow users to use whatever software the user wants to interact with the operator’s system is not in fact a principle of Free Software.
You’re welcome to want service operators to do that, but not doing it doesn’t affect any of your software freedoms.
Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
The later half -- the freedom to change the program -- is meaningless in a world of attestation. Tivoization was explicitly forbidden on these grounds: if you can modify the software, but cannot use it in its modified state, the distributor is in violation of the spirit of free software and in particular, GPLv3.
It is a basic argument from positive liberty: the freedom for services to discriminate based on user's software and the freedom of the user to be discriminated against is no freedom at all.
I think we’re just speaking different languages here.
Free software does not mandate service operators to interoperate between their own infrastructure and custom or modified software you possess. You are not somehow guaranteed access to someone else’s system just because your local code has a FOSS license.
If I said the Web Integrity API is incompatible with Free Software, would you read that as:
a) Chromium would cease to be Free Software if it implemented it; or
b) Web Integrity itself makes effective Free Software structurally impossible and exists to punish its users?
The latter is what I mean. Web Integrity or SafetyNet are a closer counterpart to this situation than your curl example. A user agent is just a hint; attestation is an effective enforcement mechanism.
No Free Software license on my client can obligate your server to cooperate. But if attestation becomes the norm across many different services, the entire framework of user choice Free Software stands on collapses.
How would Ungoogled Chromium survive if every second website rejected non-Google Chrome? We've already seen this play out with Android: more people daily-drive GrapheneOS than Lineage because it passes Google's lower-level integrity checks.
And when a "strongly advised" government app requires the strictest attestation level, will you have to move countries just to exercise that freedom of choice you supposedly have?
Ungoogled Chromium is still free software even if every second website rejects it. Free software does not have a de facto right to interoperate, and does not become less free or structurally impossible because other entities don't interact with it. The freedoms define what you can do to and with software you possess; it does not put requirements on 3rd parties to interact with you.
In the same way that commercial entities aren't guaranteed a business model just because they want one, free software isn't guaranteed connectivity to other people's systems just because otherwise it's less useful.
What they’re saying is: the FIDO spec allows website operators to specify which passkey implementations they trust for authentication to their site. If your passkey implementation does not follow the spec around how it secures secrets and validates user auth flows, you risk that some sites will not trust your software as a viable passkey option.
As a comparison: imagine I made an HTTP client called “wurl”, and it was like curl but when users used it with authenticated requests, it emitted their credentials in plaintext logs on their laptop. Site operators could say “I’m gonna block requests where the user agent is wurl, because we don’t want our users to think they’re making secure requests and not catch this credential mishandling”.
No free software principles have been broken here: site operators (relying parties) are free to determine which auth implementations they are willing to interact with. Users are free to stop using sites that block auth implementations they think shouldn’t be blocked. No primitive of free software demands that site operators interoperate with something just because it’s a FOSS client.