Comment by aleksejs
5 days ago
> The obvious way to satisfy people is to remove support for remote attestation from the spec.
If you presume bad faith on the part of basically the entire WebAuthn implementer community, how does this help?
The consumer passkey authenticator implementations of today do not provide attestations, passkey relying parties do not consume them, and both would need to intentionally ship changes to enact the scenario you're worried about. If you're worried about both of these colluding to lock you out of your accounts, it seems naive to think that changes to an (intentionally malleable, extensible) spec will protect you.
Adding support for something to the spec implies that somebody is intending to do it, or why would they add it? This implies that someone is acting in bad faith (or openly promoting a malicious feature), and the best way for the others to show that they aren't in on it is to evict them from the room and strip out the thing they were trying to insert.
Taking it out doesn't mean you don't have to remain vigilant that they might try put it back, but what does it say if they're unwilling to take it out?
It's in the spec because enterprises use it for corporate authentication scenarios, where they do have legitimate reasons to restrict which kinds of authenticators their employees can use.
Why is remote attestation required for this rather than just not issuing or enrolling authenticators you don't want?
Also, what are the legitimate reasons supposed to be that someone can't use an authenticator that follows the standard protocol but is made by a different vendor? The only thing the attestation actually does is make it so that you can't use e.g. GrapheneOS instead of Android, which has a tenuous relationship to being a legitimate prohibition.
2 replies →