Re: [webauthn] WebAuthn requirePlatformBackupEligibleCredential (#2342)

> When it comes to ensuring it has it, there is a much more negative UX if we don't allow this feature I think, as checking _after_ creation may leave a physical authenticator with a slot taken up by a passkey that can't be used, and I don't think there is a nice way to perform cleanup for the user by the RP (maybe I'm wrong, I know this area is evolving rapidly with CTAP 2.1).

Yes I know - we asked for this feature in the past where we could pre-send a aaguid list of authenticators that would be allowed to proceed. That got nerfed because "just use attestation on the server side", despite the exact issue you just raised re resident key pollution, and the bad UX. 

So the stronger way to proceed would be to try to revive that IMO. Realistically there are kind of three broad webauthn use cases today.

1) you are an org with security requirements, and do attestation - so having aaguid filtering would be amazing to prevent enrolments that you know will not succeed, and aligns closely to how attestation works.
2) you are a public website, and you just want "passkey" - so the ability to filter credentials doesn't matter
3) you are an org that loves javascript and promotes employees based on demonstrated complexity, so you want to have as many js apis as possible to pre-filter and make a complex ui before the user creates the passkey rather than relying on a platform native ui, and in the process, you accidentally prevent people enroling some classes of devices because "accidents". But at least you got your promotion. 

I think you sit in group 1 (as do I), and most websites should be doing group 2, but are very excited about group 3 despite the fact it removes user agency and choice. 

-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2342#issuecomment-3417468844 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 17 October 2025 23:08:06 UTC