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.
> 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.
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)
KeePass's userbase is negligible, banking apps didn't care about those that use rooted phones and won't care about KeePass users.
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.
A lot of bank apps refuse to work if they detect your device as rooted/failing safetynet. My bank used to do it but they either stopped caring or more probably magisk now handles it so the apps can't tell.
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.
this is wrong. you're confusing with app attestation. the other reply to this comment is also wrong.
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.
Isn’t this similar to the trust issues for the x509 CA model?
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.
Attestation is more like:
The passkey is from this model of security key/phone.
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.
Basically, for hardware backed devices like phones and physical security keys, there's an attestation certificate that is shared by all devices of that model. This can allow a site that wants higher security for some reason to require this kind of proof that the key is protected from copying in hardware (eg bound to a specific device and can't be stolen via malware, theoretically) due to it being a model known to be secure. I'm not aware of specific sites requiring this though.
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...
That seems like truly terrible advice. The only example given:
> 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.
Beautiful example of the limits of AI - it simply reiterates the comment in a seemingly informative way, but it doesn't actually understand it, so it really just states the same thing but more verbosely. Knowing nothing about Passkeys, it's also subtly wrong.
It's a bit anticlimactic how the hype is just dying down and everyone involved is just pretending they weren't just weeks ago crying wolf about the whole thing. Still I feel vindicated in my early assessment that it was mostly just empty hype about some chatbot.
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.