[lxgr]

But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users.

Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.

[valenterry]

It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.

[lxgr]

> It's still in the standard.

Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there.

I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.

[valenterry]

Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.

[lxgr]

Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost.

Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.

[valenterry]

> Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".

But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.

[lxgr]

> Seems like an absolutely rare edge case to me.

Bank and payment card transactions are arguably a pretty big part of everyday life to most people.

> I doubt there is a law that says that.

Reg E/Z in the US and PSD2 in the EU pretty firmly put the burden for these types of situations/losses on the bank/PSP. They don't specifically mandate the "how", but for better or worse, industry perception and common practice is for that to include root detection, blocking VoIP numbers from receiving SMS-OTPs etc.

> That means the law should be changed.

The law that makes banks liable for most cases of account compromise? I'm actually quite happy with that, even if it comes with some unfortunate externalities.