If that's what they want, they can have it today via OAuth/OIDC (and many sites do just that). It's not a panacea - Google & Co catch some spam accounts but not all of them and not always before the damage is already done.
Passkeys/WebAuthn improve the situation by giving site operators more choices.
oauth/oidc gives too much signal to the identity providers. it's a 1990s solution at the time advertisers were writing the specs alone. and the implementation required oath-nascar-sponsorship pattern to have dozen of providers. no bank would accept that.
webauth is a spec of this time, were it's still owned by advendors, but with a couple device vendors now for a semblance of balance. and it also solve the implementation issue of having to show too many logos on the login page.
so, no, it wasn't possible before webauth. webauth solves the oauth issues for 3rd party attestation with a semblance of anonymity (which is meaningless if both party exchange data on back channels)
My guess is that the big groups will lobby for this to be turned into a checkbox in some "best practices" list that auditors will enforce into the usual suspects in the name of "safety and security": banks, shopping sites, government sites, etc.
They are still to officially publish a spec, but already published rate limits for 3rd party apps attested requests on the official docs and since 2021 people are documenting how they are updating their IDs on AAGUID fields on already available attested requests.
passkey lack the attestation content because the spec doesn't provide for the case being discussed on another thread... cloud backed up keys.
attestation field, per current spec, must attest the 3rd party own the key and it only lives in a single placed (original intent was harware on client validated by vendor keys there)... now obviously we know apple google backup your keys on their cloud, so they cannot attest anything per current spec.
don't takes that as a instance on privacy. they are rushing changes to the spec.
as soon as they can attest keys that are shared with their clouds they will do.
Basically you’re implicitly trusting that no other CA among those trusted by common browsers will emit a certificate for your domain.
While this isn’t really nice for website certificates, and while there are some safeguards (although the strong ones got deprecated, like http key pinning) … once you go down to the granularity of a single user… not sure how that pans out.
That can then be used to have a list of allowed devices if you really need hardware backed security for example (eg you provide all your users in your org with specific security keys and don't want them registering anything else). It's not recommended to use the attestation part unless you really need it though as it restricts user choice.
Response: This comment is expressing skepticism about the potential benefits of WebAuthn, a web standard for secure authentication. WebAuthn is designed to enable users to authenticate with their credentials securely and easily without relying on passwords. However, the author of this comment argues that the real purpose of WebAuthn is to facilitate third-party attestation.
Third-party attestation is when an entity, such as Apple, Google, or Microsoft, verifies the authenticity of a user's credentials. The comment suggests that banks and other services will eventually require users to be attested by one of these major companies, effectively limiting access for those who are not attested or choose not to use attestation.
The author is concerned that the widespread adoption of WebAuthn will ultimately lead to an erosion of privacy, as large companies will gain even more control over user data and potentially use it for targeted advertising. They argue that the purported security and privacy benefits of WebAuthn are mostly meaningless and overshadowed by the implications of third-party attestation.
Me: I had no idea what they were talking about either.
What exactly is your point?
It is recommended that sites don't require it: "It is important to be aware that requiring attestation is an invasive policy, especially when used to restrict users' choice of authenticator. For some applications this is necessary; for most it is not. [...] When in doubt, err towards being more permissive, because using a passkey is more secure than not using a passkey. [...] we recommend that you do not require a trusted attestation unless you have specific reason to do so." https://developers.yubico.com/Passkeys/Passkey_relying_party...
More info: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
> It may still be useful to request and store attestation information for future reference - for example, to warn users if security issues are discovered in their authenticators - but we recommend that you do not require a trusted attestation unless you have specific reason to do so.
If that’s the only application, that communication should happen through alternate channels like your browser/OS vendor itself. Having random websites be responsible for communicating whether a given attestation may indicate compromise is less than helpful and the probability of that actually happening correctly is about 0. Oh and given all the breaches, if there is a compromise, the attacker now has a helpful list of customers using compromised authenticators.
One application seems to be to use this to try to replace captcha but I wonder what kind of impact that will have on 3p authenticators. Without extra details, it may be right to be concerned this is a massive landgrab as to how people access online services.
The real 'feature' of webAuth is 3rd party attestation.
Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one.
When you talk about webAuthn that is what you are talking about in the end. 3rd party attestation. Which in the end will be the end all "privacy respecting" (/s) advertisement profiling tech in the years to come.